Internal consistency check failed: Assertion check at "elem.c-821"

[deux_ex_machina]

I am using Retrospect 6.0.121 and attempted to make a copy of my OS (10.4.1) to a new Firewire Drive for primarily maintenance and backup purposes. Retrospect begins, and then stops with the message: Internal consistency check failed: Assertion check at "elem.c-821".

 

Here is the total messsage from the Retrospect log. You'll notice that there are quite a few references to Spotlight. -

 

7/6/2005 17:27:10: Copying Meroe RD…

Can't write file “.journalHistoryLog”, error -54 (file is busy/locked), path: “Meroe RD/.Spotlight-V100/.journalHistoryLog”.

Can't write file “.store.db”, error -54 (file is busy/locked), path: “Meroe RD/.Spotlight-V100/.store.db”.

Can't write file “store.db”, error -54 (file is busy/locked), path: “Meroe RD/.Spotlight-V100/store.db”.

Internal consistency check failed:

Assertion check at "elem.c-821"

7/6/2005 17:31:35: Execution incomplete.

[RonaldL]

Try excluding the .Spotlight-V100 directory:

 

http://kb.dantz.com/article.asp?article=7976&p=2

[deux_ex_machina]

Thanks for the assist. I used the method of changing the Selector under the Special tab. Unfortunately I got a new error: Internal consistency check failed: Assertion check at "tree.c-3444"

 

I have to add that I tried during Safe Boot as well as a regular startup, and got the new message both times.

 

Here's the Log: + Executing Immediate Duplicate at 7/7/2005 20:20

 

- 7/7/2005 20:20:2: Copying Meroe RD…

Internal consistency check failed:

Assertion check at "tree.c-3444"

7/7/2005 20:25:33: Execution incomplete.

Remaining: 87649 files, 2.3 GB

Completed: 16245 files, 218.8 MB

Performance: 40.0 MB/minute

Duration: 00:05:31 (00:00:03 idle/loading/preparing)

Quit at 7/7/2005 20:25

 

At least it appears that Spotlight isn't the issue (excuse me while I remove my brave face:) in this case.

[remfonseca]

I am having the exact same problem, in the exact same sequence: First encountered elem.c-821 error, then did as suggested here and excluded Spotlight files. Next thing, I got assertion check at "tree.c-3444".

 

My problem started when I got my new G5 Tower with OS 10.4. I am running Retrospect v. 6.0.212, latest driver update, latest client software for all my client Macs (in both OS 9 and OS X systems). I get this error ONLY when backup reaches the 2 new systems (both G5s with OS 10.4). Seems to back up everyone else OK. It does not matter if running script or doing immediate backup. All does not matter if recycle or normal backup.

 

I have been reading the thread on error elem.c-821 and have not seen that a problem has been found by anyone.

 

Still would love to hear a fresh suggestion before I call Dantz tech support.

[mjbolzan]

I am running retrospect 6.0.212 on OS X 10.4.1 backing up to file sets on firewire drives. i have excluded the spotlight files and office files and have disabled indexing via the mdutil command on the backup firewire drives. the computer's disk is partitioned into 3 volumes.

 

I now see the "elem.c-821" error only when I am doing a recycle backup. it fails at the point where it is updating the catalog for the boot disk. I click quit to the error message, the "updating catalog" message goes away, and Retrospect quits. It appears the backup is OK. I continue the backup the next night and the other two disks get backed up. All incrementals work fine.

 

Spotlight and Retrospect seem to have a problem with large files undergoing continuous updating. Based on timing and repeatability, I wonder if Retrospect is writing a temp file to the boot disk for the catalog update and spotlight is nailing that temp file? If so, maybe I could eliminate this assertion check if I knew what to exclude....

[bobio]

I'm having the exact same problem, moving from the elem.c-821 to tree.c-3444 after excluding spotlight. At that point Retrospect stops (backup), and I have to force quit. I would also love to hear a solution. I called Dantz Retrospect tech support but was told it would cost me $70.00 to talk to a tech about the program's failure. Ouch! No can afford.

[Wim Pollet]

Here too... Upgraded to OSX Server 10.4.1 Unlimited clients (10.4.2 is out just now, have to reboot) and the latest Retrospect (6.0.212) and still have this stupid nothing saying error Dantz isn't able to solve in a proper way. Machine is a dual G4 1.25Ghz, I even upgraded to 1GB ram (instead of 512MB) but this doesn't help.

[Syzygies]

I too get this error message.

 

This may be obvious to C programmers, but not necessarily to anyone else: An assertion check is intended for the programmer, not the user. It is an instruction stating: "This can't possibly happen, so I'm not going to write code to handle this; stop the program if I'm wrong." The program comes literally crashing to a halt. Unless the file structure of the program is designed to survive maliciously pulling the computer's plug, it won't survive an assert failure. So one should be concerned about the data integrity of any backup that ends with an assert failure.

 

In other words, it's a bug. It makes sense to charge users $70 to discuss issues that arise in using Retrospect. It makes no sense to charge $70 to report bugs. On the other hand, Dantz already knows about this one, it's been over a month, and no fix. What's the point of chatting about this over the phone?

 

For what it's worth, I've been a faithful customer of Dantz for close to twenty years, and this is the first assert failure I've seen in any of their products.

[ruseone]

I'm getting this error and it only started after the last OSX update which were:

 

DVD playback update v.4.6.1

&

iSync Update v.2.1

 

It would be interesting to see if this is the same for you guys???

[robross]

I just bought Retrospect Desktop 6.0 three days ago, and downloaded the upgrade so I'm now running 6.0.212. It's the first time I'm running Retrospect on Mac OS X. (Although I used to run it many years ago to back up a small network of Mac OS 8 and Windows PCs).

 

I have a PowerBook G4 15" 1.67Mhz (the latest model) with Tiger v10.4.2 (with all the latest updates as of 7/16/05. My backup volume is an external LaCie 512GB drive, partitioned into 5 volumes, connected via FireWire800.

 

I was able to do a full backup one time, but after this I continually get the "Internal consistency check failed: Assertion check at "tree.c-3444"" any time I try to do any kind of backup, whether Normal or Recycle, even when I create a new Backup set.

 

I've been trying for 3 days to get this to work with no luck. I think the latest retrospect "patch" still has major issues with Tiger.

[pt44]

Quote:

---

I'm getting this error and it only started after the last OSX update which were:

 

DVD playback update v.4.6.1

&

iSync Update v.2.1

 

It would be interesting to see if this is the same for you guys???

 

---

 

Just for information. I've also performed these updates, but I am not getting any errors - so its not directly linked to those updates.

 

Paul

[Syzygies]

Excluding the Spotlight directory, by adding "and exclude enclosing folder contains .Spotlight-V100", DID NOT help me. I get the same crash, assert failure at elem-c.821, backing up my active system 10.4.2.

 

In my experience so far, Retrospect is simply unusable with Tiger. They posted what they claim to be a working version over a month age, which contains an undeniable bug visible to all users, and no posts since. I'd think this would be bigger news, e.g. on all the Mac forums.

 

It must be that instead not everyone is catching the plague. If they weren't charging $70 to collect data on Retrospect issues, they might have more data points, and a better idea by now what to do, how I can be affected, yet so few people are affected that this isn't major news. For example, are remote backups unaffected? That would make sense, that's their main business, then there's seven of us who actually backup on solo machines?

 

I keep a separate "Boot" volume partitioned on my main drive, not for everyday use. To actually get a working backup, I'm considering (if necessary) reverting to 10.3 on that volume, and booting into it for backups. First I'd like to explore keeping it in 10.4, but having scripts which restart into "Boot", lock every other volume as read-only, make a backup, unlock the other volumes, and restart back into my primary system. I'll try it manually first, but do any of you AppleScript wizzards think this would be routine code?

 

It may be that Retrospect can't back up the active system volume for the time being (until they fix their bug). We take for granted that such things are possible, when we should be amazed the times that they actually are. It takes restarting into a different volume (the install DVD) for major upgrades to the OS.

 

It would be helpful if various of us made experiments as I'm suggesting, to come up with a workaround for the few months it'll take them to fix this bug.

[traderjim]

The install CD for Tiger won't let you run Retrospect if you boot from that CD. You are forced to stay in the installer, and the only things they let you escape to is the Disk Utility and the Startup Disk control panel. So unless you have another partition somewhere to run OSX, you are out of luck.

 

I have been getting teh tree.c and elem.c assertion checks as well, with all the latest and greatest updates for Retrospect and Tiger 10.4.2. Disk Utility and Disk Warrior say all the volumes are clean and have good directory structures, and permissions. I have Spotlight turned off (using Spotless utility), and still the assertion checks occur.

 

Excluding a significant number of applications in the Applications folder from the backup process gets past these assertions checks. However it is not a function of a specific appplication folder being excluded (i.e., it isn't as if there is a corrupted file within one of them creating this problem). Rather, it appears that the sheer size of the Applications folder and the number of folders and files within it causes something inside Retrospect to overflow and get this assertion check. If I randomly selct about four applications, any four, b=from the backup, I can get all the rest of the way through the back up without the assertion checks.

 

Definitely a fatal bug. The silence from Dantz/EMC on the issue is deafening...

[Syzygies]

I've now had two conversations with Dantz technical support on this, and I've run a number of experiments.

 

I get the elem.c assert failure after booting from a separate partition "Boot" running a minimal copy of 10.4.2, using a fresh copy of Retrospect, with Spotlight turned off and Spotlight files removed from my primary system partition. I only get the error while backing up my primary system volume "OSX", not while backing up the minimal system volume "Boot".

 

There are various advantages to a separate system volume for backups: The infamous "time zone" bug goes away, because one can leave the system volume for backups in one time zone, and change the system volume for everyday work to the current time zone. One can set Backup Server so simply booting into the separate system volume for backups provokes every possible backup, at times of one's choosing when one wants to walk away from the computer. Backing up in this way, one's primary system volume "holds still for the picture". One can arrange that the FireWire storage used for the backups only mounts while backing up.

 

Unfortunately, this scheme doesn't sidestep the assert failures.

 

My internal hard drive is partitioned into Swap (not in use), OSX, Boot, OS9, User. My primary means of backup is to external FireWire drives, using File Backup Sets. I've switched to separate backup sets for each volume that I back up (OSX, Boot, OS9, User), insuring the data integrity during this crisis of the backups for all but OSX, which draws the error.

 

I'm a programmer. If Dantz understood this bug, there would be a fix. My hunch is that the attention to Spotlight is a red herring; excluding the .Spotlight-V100 folder brings down the file count to a workable number, sidestepping the bug enough of the time to convince Dantz this is the issue. After all, one always asks oneself "What changed?", and Spotlight is what Apple touts. (Under the hood, the Developer enhancements such as Core Data are far more exciting.)

 

My next experiments will be to divide my OSX backup into pieces, hoping to escape under the radar, agreeing with other people's hunches and my experiments that the sheer number of files is a factor.

[CallMeDave]

Quote:

---

I'm a programmer. If Dantz understood this bug, there would be a fix

 

---

 

In order to understand the bug, the would first have to observe it while running in their debug environment. This would allow them to step through their code and find exactly what's happening before it fails.

 

Did Dantz provide you with a "symbolic" build of the program? This would cause the log that's generated on assert failures to contain debug information, which you could then send back to Dantz.

 

They may already have customer supplied logs, but perhaps they are unconclusive (diffrent for each customer).

 

Dantz has never claimed that they are "convinced" either way about Spotlight. The Knowledge Base article is pretty specific on the log error they say is involved in Spotlight related crashes.

[Syzygies]

I split my system backup into 3 parts (Applications, Developer, everything else) and I hit a different assert failure on everything else: tree.c-3444. This is with Spotlight off, and .Spotlight-V100 excluded.

 

There may be no alternative but to reinstall 10.3.9 on the system I use for backups.

 

(CallMeDave, I never claimed to have a debug version, though I'd be happy to run one if provided. Exactly what are you trying to say? We're both speculating in a vacuum. For the first time in twenty years I'm without full backups, so I'm experimenting, and my experiments contradict what I've been told. Give me some constructive suggestions on what my future experiments should include? We both know how how debugging works, though I prefer the insights one gets on a mountain bike to those one gets with nose to the glass, which would have worked 5 weeks ago if it were that easy.)

[CallMeDave]

Quote:

---

I never claimed to have a debug version, though I'd be happy to run one if provided. Exactly what are you trying to say?

 

---

 

I was just trying to ask "Did Dantz provide you with a "symbolic" build of the program?"

 

Since you have an open support incident with them, I was just curious if they were using you to collect the sort of information that such a build can provide. Then I posited that perhaps they already have this information, which is likely given the large number of user reports on this board.

[deux_ex_machina]

I can't get Retrospect to do incremental backups, though I can do recycle backups.

[mogilner]

I had this internal consistency check failed elem.c-821.

 

I am on a Macintosh server emac acting as a server backing up three macintoshes (no problem) and two pc's both getting this error. I would get this error right at the beginning of the backup cycle when it starts backing up the pc.

 

I was able to resolve the error by resetting up the scripts and client computer and repicking the folders/volumes that I want to backup.

 

This might be one solution to try for people experiencing this issue.

[waltr]

Quote:

---

My hunch is that the attention to Spotlight is a red herring; excluding the .Spotlight-V100 folder brings down the file count to a workable number, sidestepping the bug enough of the time to convince Dantz this is the issue.

 

---

 

excluding _6_ files brings it down to a workable number? that can't be right. my .Spotlight-V100 folder has 6 files in it:

 

.journalHistoryLog, .store.db, ContentIndex.db, store.db, _IndexPolicy.plist and _rules.plist

 

is yours different than this? i'd be really surprised if it were.

[michaeln]

Hi,

 

There are currently 2 issues that we have seen with select users regarding the Internal Consistency Check / Assertion check errors while backing up 10.4.

 

One issue is caused by the Spotlight feature as many of you know already and the workaround is to exclude Spotlight files.

 

The second issue (tree.c-3444 and elem.c-821) is a Retrospect bug which our engineers are working to track down and resolve. This is a high priority issue and we will notify you of any fixes as soon as they are available.

[deux_ex_machina]

I am currently (with baited breath) almost through an incremental backup with Retrospect 6.0.212 and Mac OS 10.4.2. I don't quite know why it is working now, as opposed earlier but it seems to be doing it. I want to verify the copy, to be sure but it appears to be doing well.

 

What I did, besides exempting Spotlight files, was to repair Disk Permissions with Disk Utility on the computer in question as well as via the Tiger startup disk. I also ran TechTool 4 on my computer (because the original intention was to install a eDrive on my computer, the installation of which was not working as planned) as well as repaired permissions from my emergency maintenance copy (essentially a copy of 10.4.2 without any unnecessary programs) on another hard drive.

 

I did lots of redundant things, with no rhyme or reason (mainly because my intention was not to deal with Retrospect), though perhaps someone more adept at these things can puzzle something out.

 

I will make my log of the current backup available if anyone requires it.

[Syzygies]

YES!!! Two words: REPAIR PERMISSIONS

 

I have tried many things, as my prior posts indicate. After reading the above post, I repaired permissions and tried again, backup succeeded without incident. No assert failures! My current setup:

 

1. Spotlight is disabled for my system volume. (My home directory is on a separate user volume, for which Spotlight is enabled.)

 

2. Spotlight is running, so I can search inside Mail, etc.

 

3. I exclude enclosing folder named ".Spotlight-V100" in a custom selector.

 

4. I repaired permissions just before backing up.

 

As I had already tried everything but repairing permissions, to no avail, this should be an interesting clue for those searching for the bug. Good luck!!

 

(I must confess, I have no idea why permissions get out of whack in the first place.)

[Syzygies]

Since repairing permissions, I have completed a second backup without incident. The above success was not a fluke.

 

I did however get one very odd log entry, while backing up my spare system volume "Boot":

 

Quote:

---

Can't read file “Env: : : : : : : :.htm”, error -43 (file/folder not found), path: “Boot/System/Library/Frameworks/Tcl.framework/Versions/8.4/Resources/Documentation/Reference/Tcl/TclLib/Env: : : : : : : :.htm”

 

---

 

There is no file “Env: : : : : : : :.htm” in that directory. Curiously, there is a file named “Environment.htm” in that directory, which was NOT backed up. Note the same string length. (I have inserted spaces between the colon characters to avoid creating clapping hands "Instant Graemlins" in this forum post. In the actual file name reported by Retrospect, there are no spaces between the colons.)

 

I have no direct knowledge of Retrospect's code. However, in my own code when I have assert errors and garbled strings, it is usually a "wild pointer" caused by allocating the wrong structure somewhere, of too short a length. Such a bug in a complex program can take forever to find, because where the program falls dead (the assert failure) is rarely anywhere near where the program was shot (wild pointer).

[Guest]

Try excluding the enclosing folder 'cache'. this worked for me! eitherway, cache does not need to be backed up and mac os x stores a lot of it...