CallMeDave Posted October 23, 2004 Report Share Posted October 23, 2004 >I'm sorry Dave but I have to respectfully disagree. The respect is _highly_ appreciated. My comments are given in the same vein. >I use memory hogs, such as Mathematica, frequently but only Retrospect is giving me problems. I wasn't promising that _your_ issue was caused by faulty RAM. I was commenting on the apparent solution that new memory modules provided to Eric. As Mayoff said above, these particular errors are not always caused by the same thing. >For tech support not to peruse the Forums from time to time to survey what problems >people are having is a mistake. I agree. Mayoff and NateW do post to all the different parts of the Forum, while AmyJ and The Fabulous Irena seem to be gone and missed. But Dantz has always been clear that this BBS is unsupported. I'd guess that they take the bulk of their problem feedback from support calls. >After at least 6 months of discussion of this problem on the forums, >it seems that tech support is still not aware of the problem. Am I >the only one who doesn't see a problem with this? If that were true then I'd see a problem too. And while it's possible that whoever Tom spoke with didn't know the issue, Mayoff's post makes clear that tech support does. And while it's helpful to have an error number to help diagnose, the only way to know exactly where a program is barfing is to run it from within a debugging environment. And that takes source code. >The "canary" excuse which I have heard repeated many times just doesn't >cut it. If Retrospect is so fragile(?) perhaps Dantz should consider more >informative messages and a more robust design. I don't think the metaphor was being offered as an excuse. I think it was being offered as an observation that the program makes intensive use of computer subsystems; memory, I/O, SCSI, etc. Fault tolerance is a good thing, to be sure. But it would be pretty difficult to design around hardware malfunctions. >I have had this problem on both machines that I have used retrospect >on using different drives, different scsi cards, different memory, >different cables and different tapes. Now, there may still be >undetected hardware/system problems with both machines but if Retrospect >is the only software failing as a result then there IS a problem with Retrospect. I don't understand. If there is really _were_ an undetected hardware problem, how would that be a software problem? Other then this program, are there _any_ things common between setups? >With the exception of one other company whose name I wont mention, Dantz is at >the bottom of my personal favorites list. Fortunately for them they have a monoply >in the Apple market for backups to tape. I don't like companies that seem to go out >of their way to make it difficult for customers. I don't like companies that do that either. Are you suggesting that Dantz does? The very fact that Dantz tech support is willing (and able) to answer _any_ question on a free BBS speaks to a level of customer satisfaction that is usually only seen with small developers. It's true that the major players such as Adobe will provide some level of free electronic support for their registered customers, Dantz seems to be trying to balance customer support with the need to stay in business. Perhaps their support model will change now that they've been absorbed into a larger business. Hopefully not for the worse. >I am glad for 'ericrow' that his problem seems to be fixed. For me the problem >is intermittent; even though I haven't had it occur for a week or so I am not willing >to say that its gone. Does learning from Mayoff that assertion check errors in Retrospect can be diagnosed by tech support all the way to the engineering level encourage you to consider paying for help? In all my experiences with their tech support they never closed an incident until there was a solution. Seems like $70 is a reasonable cost to help ensure that all your backups are trouble-free. And if, in the end, the problem _is_ a software defect, you can and should ask for a refund. I know they've done that before. >May all your backups be trouble-free and never needed... See above. Dave Link to comment Share on other sites More sharing options...
kinger460 Posted October 26, 2004 Report Share Posted October 26, 2004 well, lookie here! looks like i finally found the Holy Grail thread for elem.c-XXX assertion check failure errors. yippee!! hey, from the long and exciting posts it looks like y'all are havin' a grand old time chasing yer tails on these little buggers (pun intended). since i got no reply on my first 2 "wild" posts (i.e., not of the Holy Grail thread) i thought i'd join the crowd here (misery loves company, eh?). anywho... my own "special" (they are VERY unique aren't they?) elem.c-811 assertion check thing-a-ma-jiggy occurs on 2 different Macs now; one being a Ti 800/1GB RAM and the other a brand spankin' new G5 Dual 2GHz/2.5GB RAM. even with the latest version updates, Retro still crashes when attempting a restore from an older (pre v6) catalog. since this could be attributed to any one of 25 or more "faulty" hardware issues - as noted in many posts before mine - i will now venture into the tech support realm and report back after i've had my shock treatment... or 2 i know this is a free forum and i thank you for it, but some of your moderator replies crack me up, dudes! keep it real. FYI - i bought Tolis Group's BRU LE for Mac OS X and... it works like a charm! so much for that "monopoly" in the Mac backup market. Link to comment Share on other sites More sharing options...
BrettConlon Posted October 27, 2004 Report Share Posted October 27, 2004 Just to add my 2¢ worth.... I have the c-811 error whenever scanning my Art Archive 6 backupset while doing a Restore under OSX. It scans and restores fine under OS9 but whenever it is searched under OSX it forces the error. The other 14 archives we have work fine under OSX too. According to the Dantz Knowledgebase, as pointed out by Mayoff (many thanks!), it points out - regarding my specific case: ------------------------------------------ Matching during a restore If you get the error during restore preparation during the Matching phase, you likely have a corrupt catalog. Follow the tips in the note above for "Matching During a Backup." ------------------------------------------ Then in the "Matching During a Backup" section it states: ------------------------------------------ The best way to recover from this is to rebuild the backup set catalog from the media, using Tools>Repair in Retrospect..... ------------------------------------------ This will be my next move but there are 5 AIT tapes in that backupset and that will amount to approx 2 days worth of rebuilding.... our Retrospect setup is used for both nightly backup and for archiving/retrieving work and is used by our designers pretty much all day. This will be a serious interruption to our workflow. At least we haven't lost all of that work though.... small graces! Link to comment Share on other sites More sharing options...
rickb Posted December 15, 2004 Report Share Posted December 15, 2004 Just want to report that the since the last update (6.0.204). I have been trouble-free for two months. Woohoo! Link to comment Share on other sites More sharing options...
wmconlon Posted December 23, 2004 Report Share Posted December 23, 2004 I'm just about to send a letter to EMC. I have been a loyal Dantz customer since ca 1989 running Diskfit to backup my AppleShare 2 server. For years, 4.3 ran flawlessly on my AppleShare 6 server, backing up a mixed Mac/PC network to DAT. But I added a linux system to the mix and was forced to upgrade to Retrospect 5 and 6. In the last 12 months, I have never successfully backed up 7 days in a row!!. This is an incredible horror story, which has consumed countless hours, and gives me nightmares. I regularly get Assertion check elem.c-821, and the damn piece of junk just sits there. You would think the least you incompetent developers could do is restart the application for me and try it again. There's virtually no worthwhile support, and no logging of any value in clients or server. I can't see ever recommending Dantz to anyone. Link to comment Share on other sites More sharing options...
CallMeDave Posted December 23, 2004 Report Share Posted December 23, 2004 Quote: But I added a linux system to the mix and was forced to upgrade to Retrospect 5 and 6. There's something you're leaving out. Retrospect 4.3 ran only on Mac OS 9, while Retrospect 6 runs only on Mac OS X. So you not only changed to the newer versions of the program, you also changed to a newer version of the operating system. Given the major change you made from OS 9 to OS X, hardware issues come into play and can't be dismissed. Are you still using the Beige Powermac G3, OS X.2.8 (all patches applied), 320 MB RAM, Retrospect 6.0.193 with latest driver pkg, APS DDS-3 DAT (Sony SDT-9000) attached to motherboard SCSI adapter? NateW made two seperate posts regarding your configuration; one asking about your SCSI pin-out, and another informing you that OS X does not provide adequate SCSI support when run on the legacy Macintosh with built-in host adapter. He didn't mention the absolutely paultry amount of RAM you're providing to a very RAM intensive application. In fact, according to this article: http://docs.info.apple.com/article.html?artnum=106163 Apple didn't support any version of Mac OS X on the Beige G3 (although the page contains a link to a more specific info page, but it's for Panther, although the same link is included in numerous 10.2.x specific pages, leading me to believe it's an Apple support page problem). If your problems are occurring on this hardware, and you've been informed that the hardware is incompatible, then it's not incompetence on the developer's part; it's more of a deficiency in the organic interface between the monitor and the keyboard. Dave Link to comment Share on other sites More sharing options...
wmconlon Posted December 23, 2004 Report Share Posted December 23, 2004 1. I ran Retrospect 5.1 on OS9 on the same machine that had been running 4.3. So it's not just changing OS -- it's Retrospect. 2. Regarding hardware configurations, the one you cited is only one of many I have tried. It happens to still be my desktop. The only reason that one came into the thread is Dantz support's assertion that I should try backing under X. At the time that was the only X system in our shop. In addition to that system, I have tried: a. PowerMac 7300, Sonnet G3/400, 320 MB RAM (balanced DIMMs), MacOS 9.1 to: SCSI DAT b. same as a, OSX.2.8 to Firewire HD c. Powermac 7600 108 MB, unknown G3/400 upgrade, MacOS 9.2.2 to SCSI DAT, Firewire HD d. iMac DV SE (400 Mhz, 384 MB) MacOS9.2.2 to Firewire HD e. same as d, MacOSX.2.8 to Firewire HD f. same as d, Mac OS X.3.6 to Firewire HD I think my suite of hardware tests is sufficient to convince me that there something rotten in Retrospect. 3. Regarding the paltry amounts of RAM, I think you've hit the nail on the head. Retrospect has a history of failing when there is paging. Readers may recall that Retrospect would not run with Virtual Memory on an AppleShare system. But under *NIX, why should Retropsect care. The only issue with paging should be speed, not failures. My instinct tells me there is something subtle about how you build and manage memory resident indexes. But since it's been broken for so many years, how about keeping all your data in mySQL, instead? 2. I am sure that backup failures were due to hardware2. I Link to comment Share on other sites More sharing options...
wmconlon Posted December 23, 2004 Report Share Posted December 23, 2004 Let me add one other point, that should relevant to EMC CEO. You guys are in the data protection business. If there is a risk of loss of data because something has failed in my hardware, I expect you to protect me. If that means Retrospect needs to run memory checks and interface tests, so be it. But this forum is littered with people who can't get their data backed up, and worse still, can't retrieve it. It 's unconscionable. Link to comment Share on other sites More sharing options...
wmconlon Posted February 19, 2005 Report Share Posted February 19, 2005 ok, finally identified the problem. Retrospect has a race condition that causes it to damage its catalog. So here it is in a nutshell. I'm running old hardware -- a powermac7300 (50MHz bus) with a Sonnet 400 Mhz G3 upgrade card. When I back up to firewire (400 Mbps) hard disks, Retrospect will NEVER run a full week, usually much less, before halting with an assertion check, consistency check or checksum error. This has been going on for more than a year, so I finally pulled out my old DDS-3 DAT drive and hooked it up to the external SCSI connector (5 MB/sec). Lo and behold -- no errors. Backed up everything on the network, some 80 plus GB, over some three days. (It's not an autoloader, so it depends on me to change tapes. Sure would be nice to get an email alert). I have run the DAT backup script regularly without trouble, but the scheduled firewire backup fails as regularly as ever. I just finished another trouble-free backup to a new DAT backupset. Again problem free! So what's happening? A race condition between the cataloging threads and the I/O threads. When I/O is faster than cataloging (my case with a slow computer and fast disk) The catalog gets out of synch. But slow down the I/O and Retrospect can keep up. Kind of suggests an explanation for the old OS 9 Virtual Memory problem -- paging out the catalog probably slowed it down too much. This also explains the "superstition" in this forum that faster/better hardware is needed to run Retrospect. So how do fix this? Dantz would have you buy fast processors to cover up their sloppy programming. I kind of would like to see this race condition removed, however, since it is a long-term, persistent bug. Link to comment Share on other sites More sharing options...
natew Posted February 22, 2005 Report Share Posted February 22, 2005 Hi Its important to note that Retrospect 5 is much different that 4.3 because it relies on carbon lib. I have seen a number of instances where the drivers and firmware for CPU upgrade cards would fail with carbon based applications. The fix was to upgrade firmware and drivers for the cards and voila, no errors. I would guess something similar is happening in your case. Thanks Nate Link to comment Share on other sites More sharing options...
wmconlon Posted February 23, 2005 Report Share Posted February 23, 2005 You miss the point completely. Disk backups don't work reliably. DAT backups do work. Same system, same software. What's the diff? Speed. Retrospect can't keep up with itself. The problem is Retrospect!!!!!!! Link to comment Share on other sites More sharing options...
CallMeDave Posted February 24, 2005 Report Share Posted February 24, 2005 Although you reference configurations "d" and "e" above, you don't provide the results of tests on that machine. And your 2/19/2005 post referres specifically to unsupported hardware. It doesn't matter how you might be able to coax unsupported hardware to work, what matters is that the program is ony tested on hardware that the OS vendor certifies will boot the system. Apple doesn't support processor upgrade cards (especially on these legacy motherboards), and neither does Dantz. If you can reproduce the problem on the iMac DV SE (400 Mhz, 384 MB) running OS X 10.3+ to a FireWire hard drive (preferably a different drive the the one that's showing the problem) then you might be able to describe a softwre defect. But complaining that Retrospect has a problem working within unsuported legacy hardware isn't going to earn you a lot of sympathy from the community at large. Link to comment Share on other sites More sharing options...
wmconlon Posted February 24, 2005 Report Share Posted February 24, 2005 I'm not looking for sympathy. I've described a verifiable, repeatable defect, whose simplest explanation is a race condition, i.e., a threading problem. Explain this: a machine ("supported" hardware or not) runs a full backup to DAT just fine, with millions of files and the backup lasts 3 days. But running on the same machine, even an incremental backup of a few thousand files to disk is unreliable. I'm sorry it wasn't clear that backups are similarly unreliable on systems d and e. And by the way, there are two different firewire hard drives in the mix. So I think that qualifies as showing that it fails on "supported" hardware. There have been assertions in this forum that Retrospect is somehow a hardware stress tester -- that it provides a great stress on a system and thereby exposes latent defects that no other software exposes. Possible I suppose, but extraordinarily unlikely. The fact that slower backups are flawless, in combination with failing fast backups on different hardware, suggests a defect in Retrospect is far more likely. Other than Retrospect failing, the system in question (the PowerMac 7300 with a Sonnet G3 upgrade running X.2.8) never crashes. It runs as a file server and never needs a reboot (though it gets one sometimes when Apple provides a security update). And re-booting it doesn't seem to make Retrospect run better. Since this is the most popular thread on the forum, I've got to believe this not just my "unsupported" hardware. Of course, it's possible that many of us have defective hardware (supported or not) and the assertion/checksum/consistency errors are indicative of those defects. But if that's the case, Retrospect should (as I've posted elsewhere) provide some graceful means of handling and reporting these errors. Retrospect doesn't do that. The way I find out Retrospect isn't working is by NOT getting an email saying a Script is finished. I can't be the only one who thinks this logic is inverted. I would prefer to get notified when something goes wrong. But that's the subject of another thread. I only hope that Dantz will structure some tests to look into this. Link to comment Share on other sites More sharing options...
NickG Posted June 6, 2005 Report Share Posted June 6, 2005 Quote: I had precisely this problem on my OSXS 10.2.8 machine. I cleared it by using a new backup set, using Onyx to repair permissions, empty caches, redo prebinding (optimize), in fact I ticked every box on the Automate tab!, and then I rebooted the server. It has been fine since. Sadly my optimism was misplaced. Ever since, this server still running OSXS 10.2.8 exhibits this annoying error which stops the automatic backup dead in its tracks until one of my colleagues complains that thir achine is displaying a message saying it has not been backup up since..... last week or worse. Periodically I follow my own advice and it is OK for a few days but essentially once a week or so Retrospect ceases to function and fails to notify anyone! Full spec Quicksilver Dual 800MHz G4, 1.5 Gb RAM, 80Gb and 128Gb HD, 100baseT ethernet Isn't it about time an official solution to this problem was found? How about an auto-dismiss for the error message after 2 hours? Or an email to the admin? Link to comment Share on other sites More sharing options...
AntonRang Posted June 10, 2005 Report Share Posted June 10, 2005 Well, I just had this error (elem.c-821) occur for the first time in 10+ years of using Retrospect. I have a G4 cube running Retrospect 6.0.212, Mac OS X 10.4.1, with a LaCie/Sony AIT-1 tape drive attached via FireWire. I had reset an old backup set and manually erased its first tape, then started an immediate backup of the local desktop (two volumes, my main disk and locally mirrored iDisk). My catalog file was thus empty when I started. The error apparently occurred just as the backup was transitioning from writing to comparing on the main disk. The only out-of-the-ordinary event was that I had wound up deleting a large package after Retrospect had done its scanning, but before it had written those files to disk. I thus had a lot of file-not-found messages in the log. Usually I do my backups on a quiesced system. Perhaps this is a clue? Link to comment Share on other sites More sharing options...
CallMeDave Posted June 10, 2005 Report Share Posted June 10, 2005 Quote: The only out-of-the-ordinary event was... Well, it's still pretty novel for you to be running Tiger, as the OS has only been out for a matter of weeks. Did you create a selector to exclude the Spotlight files, as outlined by Dantz in their KB entry? http://kb.dantz.com/article.asp?article=7976&p=2 Link to comment Share on other sites More sharing options...
trustworthy Posted June 10, 2005 Report Share Posted June 10, 2005 I created a Spotlight selector and get the same problem. IMO Dantz has allowed this issue to fester. I'm looking for a replacement. BTW Apple seeded Tiger to developers long before it was sold to the public. Link to comment Share on other sites More sharing options...
ProfN Posted June 11, 2005 Report Share Posted June 11, 2005 "BTW Apple seeded Tiger to developers long before it was sold to the public." That's true, but Apple's programmers were making a lot of changes in Tiger throughout the period between initial seeding up to the public release. I respect Dantz developers for fairly rapidly bringing out a Tiger-compatible version of Retrospect. From what I've gathered in donating my time as a volunteer beta tester (not to Retrospect) Apple and lots of developers, however, discover with every new release or update that the unimaginable number and diversity of hardware and software configurations that exists in the user population allows for bugs. Fix one bug and, as I discovered during my beta testing, it's not uncommon for another bug to be created for some hardware-software combinations. I'd be happy if I didn't have to exclude .Spotlight V-100 as a file, and have a separate exclusion for .Spotlight-V100 as an enclosing folder on each volume on each hard drive on which I run Retrospect. But I'm aware that there are problems within Spotlight, itself. And while Apple programmers do whatever fixes are needed, and while Dantz developers sweat the workarounds for Spotlight and other issues (which I appreciate), I think I can be patient for a little longer. I've posted my own issues in this forum and I've been pleased with the support. As a consumer, I've alerted Retrospect tech support when I've had problems and have found them responsive. Respectfully, Norm Link to comment Share on other sites More sharing options...
AntonRang Posted June 12, 2005 Report Share Posted June 12, 2005 Tiger is fairly new, but the existing file system APIs have not changed significantly (as long as you haven't enabled ACLs). Given that others have been seeing this particular assertion failure for some months/years, it doesn't seem that Tiger is the cause. (Anyone at Dantz care to comment on what exactly is being tested in this assertion? Perhaps it might help us figure out what's triggering it.) My normal selectors, including the one I was using for my backup, do exclude the spotlight index folder. (First change I made since getting Tiger, actually. :-) For what it's worth, I've successfully done full backups to two backup sets since installing Tiger. This is the first time I've gotten the error. Sadly, it's also the second time -- when I restarted the backup to the same backup set, after resetting it, I got the same assertion failure, even on a quiesced system. There were no errors or warnings in the log. Retrospect logged the following (identical, except for the date, on both occasions). Retrospect Problem Report date: 6/11/2005 10:30 PM version: 6.0.212 Internal consistency check failed: Assertion check at "elem.c-821" Stack Crawl... DATA_0000 +50948 DATA_0000 +12ab2c DATA_0000 +2cb10 DATA_0000 +1e004 DATA_0000 +66954 DATA_0000 +34254 DATA_0000 +19ae18 DATA_0000 +34254 DATA_0000 +18e064 DATA_0000 +59de4 DATA_0000 +34368 DATA_0000 +5a064 DATA_0000 +18e7cc DATA_0000 +59de4 DATA_0000 +34368 DATA_0000 +5a064 DATA_0000 +18ebf0 DATA_0000 +34254 DATA_0000 +101e28 DATA_0000 +34254 DATA_0000 +109454 DATA_0000 +59de4 DATA_0000 +59fe0 DATA_0000 +59de4 DATA_0000 +59fe0 DATA_0000 +109518 DATA_0000 +59de4 DATA_0000 +59fe0 DATA_0000 +2cd60 DATA_0000 +59de4 DATA_0000 +59fe0 DATA_0000 +2ce58 DATA_0000 +2cfb4 I've been resetting the SmartSet; I'll try deleting it instead, and retrying the backup. If that fails I'll try switching media, though I'm not getting any media errors reported. Link to comment Share on other sites More sharing options...
wse Posted June 12, 2005 Report Share Posted June 12, 2005 I am also seeing this error: MacOS X 10.4.1 Retrospect Desktop 6.0.212 RDU 6.0.3 TiBook 667 MHz backed up to an AppleShare drive. It seems to be failing consistently on an HTML file inside /Developer. What is nasty is that Retrospect then hangs and has to be force quit. I have just forced Retrospect to recreate its Preferences, and recreated the script and backup set. Is there any point in running a file system or disk check (fsck? Disk Utility? DiskWarrior?) on either source or target disk? Any insights appreciated. -- Bill Link to comment Share on other sites More sharing options...
AntonRang Posted June 12, 2005 Report Share Posted June 12, 2005 Same error after deleting & recreating the backup set. I tried backing up another computer (a client) first this time, which succeeded. The client was also running 10.4.1. The local backup, which of course didn't include all files this time around, still failed with the error at the same point. Maybe if I were around to watch it I could catch the file causing the error. I'm still uncomfortable with the fact that the verification phase didn't run because of the failure, and I'm unsure I'd be able to recover the full disk from this backup set if I had to. Perhaps I'll track down a spare device to do a test restore. Link to comment Share on other sites More sharing options...
NickG Posted June 13, 2005 Report Share Posted June 13, 2005 I seem to have stirred something up, lots of people with the same old problem! "As a consumer, I've alerted Retrospect tech support when I've had problems and have found them responsive." I hope they live up to your expectations this time. Link to comment Share on other sites More sharing options...
ringg Posted June 13, 2005 Report Share Posted June 13, 2005 [\quote] ...so I finally pulled out my old DDS-3 DAT drive and hooked it up to the external SCSI connector (5 MB/sec). Lo and behold -- no errors. So how do fix this? Dantz would have you buy fast processors to cover up their sloppy programming. I kind of would like to see this race condition removed, however, since it is a long-term, persistent bug. I would like to return to wmconlon's post of 2/9/05...I, too had various assertion check errors on a G4/400, OS 10.3.8, 512MB RAM, Retrospect 6.0.204, RDU 6.2.102, Quantum Valueloader with an SDLT320 drive, ATTO UL4S SCSI adapter. After several months of tech support from Dantz, ATTO, Quantum and Apple, I solved my problem by decreasing the speed of the SCSI adapter to 20 or 10 MB/sec from the default 320 MB/sec. using the ATTO configuration utility. To quote mwconlon "Lo and behold -- no errors". I can recreate the assertion errors by increasing the SCSI adapter speed. In both of our cases the solution lay in decreasing the communication speed between the computer and the peripheral device. wmconlon apparantly knows much more about writing code than I do, but I think that he might have hit the nail on the head in that the problem might lie in a race condition between the I/O and cataloging, with the I/O device outrunning the cataloging. I used to think that I had an incompatibility between the fast SCSI card and the slow PCI bus speed (66 MHz). However, I have to slow the SCSI down to 10 or 20 MB/sec in order to run error free. If I increase the SCSI adapter speed to 40 MB/sec I begin getting the assertion check errors again. My main complaint with this forum is that someone suggests a solution to a user's problem, and the thread is suddenly dropped by the user with the problem. We never learn if the suggestion helped or not. In this case wmconlon suggested a programming deficiency. This forum is monitored by two moderators who have offered suggestions on this thread in the past. With all due respect, our moderators have left us hanging and flailing around to try various solutions when the problem might lie in the software itself. So, Mayoff and Nate, the ball is in your court. Is wmconlon's suggestion correct? Have you consulted Dantz engineers about the possiblility of a race condition existing between I/O and cataloging? Have Dantz developers addressed this issue? Does v.7 catalog differently so that this problem won't occur. I think that we users who have experienced this and other problems have a right to know if/what Dantz is doing about I/O incompatibilities. Thanks Link to comment Share on other sites More sharing options...
fondamacs Posted June 15, 2005 Report Share Posted June 15, 2005 I've been using Retro since they wrote it for the Mac, when '90±?, thru upgrades and purchases when I let it go a little too long. It's always functioned flawlessly, I never needed nor asked for tech support. Purchased v6.0.178 last year for new PMac DP G5 and PBook 12. It too worked perfectly thru 10.3.9. Along came Tiger! I waited 'till June to buy in. Upgrade Retro to v6.0.212. Oh, nuts! -821 errors – called and hollored until I got some help – excluded spotlite in the selectors – things were looking good again. B/U's almost done – now an assertion chk. failure at "tree.c-3444"! Can anyone help before I spend 40 minutes on hold again? Thanks! Link to comment Share on other sites More sharing options...
maxhowarth Posted June 15, 2005 Report Share Posted June 15, 2005 fwiw any errors i've had with retro6 (tiger) crashing has been resolved by making the folder names shorter. i haven't worked out what the exact limit is but folders like 10071|Xxxxxx|xxxxxxx xxx xxx backup where 10071|Xxxxxx|xxxxxxx xxx xxxxxxx xxx xx won't. this is backing up our raid0 project folders on a dual 2.5 g5 with 10.4.1 booting up from exf fw800 drive (the two internal drives make up the raid). Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.