Jump to content
Sign in to follow this  
Mayoff

Elem.c-812 workarounds

Recommended Posts

Hello folks,

 

 

 

I just got an elem.c-812 assert. The backup was started yesterday and had been waiting for a MO disk for about 16 hours. When I put the new disk in it asked to erase the disk and then quit with the error. Retrospect 5.0.205 - Fujitsu Dyna MO 1300 FE drive. Mac OS X.1.4. G4 cube with 384 Meg of memory. Brand new Easy Script backup.

 

 

 

Thanks,

 

John

Share this post


Link to post
Share on other sites

Dave-

 

 

 

Thanks for the advice. It continued to happen under File Sets. I am currently running a successful backup of my Shared folder on the server with the server as a client (not a mounted volume). I'll do a test tomorrow with each of the root directories set as volumes and see if it persists. Sorry this took a few days, I had a few other distractions (finally my backup server isn't the largest of my headaches).

 

 

 

alex

Share this post


Link to post
Share on other sites

Well, I set each root level directory as a volume, and all looked good to begin with. Then it hit 'Shared Items', the folder which contains my share points, and after doing a full scan off the files, that is where it came up with the elem.c-812 error. I 'forgot' 'Shared Items' as a colume, defined the shre points themselves as volumems, and managed to back up every volume/directory without a problem. So, there must be some issue with a particular file in the 'Shared Items' directory itself which is not actually within any of the shre points.

 

 

 

Mayoff, Dave, any ideas of where to go from here? Should I send the assert error log onto anyone? Thanks for all continued help!

 

 

 

alex

Share this post


Link to post
Share on other sites

*UPDATE*

 

 

 

Some customers have reported problems when backing up AppleShare IP servers with both Retrospect 4.3 and 5.0.

 

 

 

There is one problem reported with Retrospect 5.0 running on an ASIP server, where Retrospect is definitely not the cause:

 

 

 

The ASIP server crashes when Retrospect 5.0 autolaunches or is launched from an alias.

 

 

 

We have identified this to be a problem between Mac OS 9 and the ASIP software that may occur when any Carbon-style application is launched from an alias. We have duplicated this behavior using other Carbon applications, and we have reported the issue to Apple.

 

 

 

Other reported problems currently under investigation include:

 

 

 

Retrospect 4.3 running on an ASIP server asserts failure or hangs during the backup's copy phase.

 

 

 

The ASIP server locks up when the first user logs in following a backup of the server with the Retrospect 4.3 client.

 

 

 

The ASIP server crashes at the beginning of a backup with the Retrospect 5.0 client.

 

 

 

Retrospect returns "error 1 (unknown)" for some files backed up from an ASIP server with the Retrospect 5.0 client.

 

 

 

Due to the complexity of the AppleShare IP software and the difficulty in reliably reproducing these behaviors in a controlled environment, Dantz has been unable to establish that Retrospect is the cause of these problems. As such, we have opened a developer support case with Apple to determine the root cause of these issues.

 

 

 

We consider this to be a matter of the highest priority, and we will provide additional information on these issues as soon as we have anything significant to report.

 

 

 

Thank you,

 

 

 

Dantz Technical Support

 

 

Share this post


Link to post
Share on other sites

I've been getting the dreaded Internal Consistency Check failure: Assertion Check at "elem.c-812." Got the error twice today.

 

 

 

I'm running OS X 10.1.4, and Retrospect 5.0.205. I got the error today while backing up the main drive on my Powermac G4 Gigabit Ethernet, backing up the same volume that Retrospect resides on. I'm backing up to a DVD-RAM drive that I installed to replace the original CD drive, and this DVD-RAM drive has worked perfectly up until now with Retrospect.

 

 

 

I know it's not the catalog file, because it was a brand new catalog. I trashed the old one and started a new backup, creating a fresh catalog.

 

 

 

One of my clients is an OS 9 machine, but the error came before the app had started on that machine over my ethernet. (Another client connects over wireless.)

 

 

 

Is there any known fix? Should I reinstall Retrospect?

Share this post


Link to post
Share on other sites

Some users with the new Retrospect Driver Update have reported this problem. If you are running the Driver Update, and you do not own a VXA tape drive, try removing the driver.

 

 

 

Dantz is aware of this problem and working toward a solution.

Share this post


Link to post
Share on other sites

I was getting the elem.c-812 Assertion check in OS X every time I backed up a local volume to a disk file. This occurred at the very end of the backup, just before verification. It didn't happen backing up to CD or tape. This is with 5.0.205. As suggested, removing the 2.6 driver update cured the problem.

Share this post


Link to post
Share on other sites

Hello,

 

 

 

Dantz has been investigating several problems that customers have reported when backing up an AppleShare IP server with Retrospect 5.0. Reported problems include:

 

 

 

1) The ASIP server crashes when Retrospect 5.0 autolaunches or is launched

 

from an alias.

 

 

 

2) The ASIP server crashes at the beginning of a backup with the Retrospect

 

5.0 client.

 

 

 

3) Retrospect returns "error 1 (unknown)" for some files backed up from an

 

ASIP server with the Retrospect 5.0 client.

 

 

 

Our investigation has revealed that these problems result from using Carbon APIs with AppleShare IP software. Problem #1 occurs when any Carbon application is launched from an alias, confirming our contention that it is not a Retrospect issue. Retrospect 5.0 uses HFS+ file system calls, as specified by Apple, which stimulate bugs in the AppleShare IP software,

 

resulting in Problems #2 and #3.

 

 

 

We have reported all of these problems to Apple, but Apple's development efforts are now focused on Mac OS X Server. Without a commitment by Apple to address these problems, we have no choice but to suggest that our customers consider replacing AppleShare IP with Mac OS X Server.

 

 

 

Sincerely,

 

 

 

Dantz Development

 

Technical Support

 

www.dantz.com

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×