SD 2.1: error processing extended attributes: Cannot allocate memory
 

Just upgraded to 2.1. When it ran, I recieved 5,000 syslog lines of....

" /Applications/SuperDuper!.app/Contents/MacOS/SDCopy: error processing extended attributes: Cannot allocate memory"

Nothing has changed in my configuration, except the upgrade to 2.1.

Ideas?

This is a (pointless) diagnostic printed by an OSX call we're making; it's quite annoying, but we need to make the call to properly copy certain types of metadata...

Thanks for the response. However, today this generated 56,000 lines in my syslog. Would it be possible to provide a link to download the previous 2.0.1 version, that did not induce these messages? Thanks.


EDIT: Found 2.0.1 at download.com

While you might have had a lot of logging during an erase-then-copy, subsequent Smart Updates will log far, far less... I'd really suggest sticking with 2.1...

I also found thousands of similar messages in the system log asl.log the first time running version 2.1 -- this was a smart update. The messages are like this:

[Sender /Applications/SuperDuper Folder/SuperDuper!.app/Contents/MacOS/SDCopy] [PID -1] [Message error processing extended attributes: Invalid argument] [Level 4] [UID -2] [GID -2] [Host xxxxxxxx]

xxxxxxx is the name of the host computer

This asl.log file is 18 Megabytes and it's mostly SD messages like this! Is there something wrong or is this expected? The size of the file worries me. I haven't tried to boot yet from this clone but does this look normal?

At present, there's nothing we can do right now, unfortunately, but we're looking again. The call that does the EA copying are logging in a weird way when they find unusual structures on the drive.

It might help to repair the startup volume -- not permissions, but the drive itself. You'll usually want to boot from your Tiger install DVD and run Disk Utility from the Installer or Utilities menu to do that.

(For the curious, those who have permission from Apple can look at where the logging is coming from by navigating to this page -- the errors are coming from copyfile_xattr, which is called from SD under Tiger, via copyfile, to copy the EAs.)

These have all been Smart Updates. The first one was 5,000 lines. The next 3 were all 56,000 lines.

OK. Try what I suggested above and repair the drive. Make sure to only use Tiger-qualified tools: repairing with old versions of DW (etc) might be corrupting the EA part of the directory structure.

I did the following .....

1) Booted from Tiger install CD and ran Disk Utility - Repair Disk. The results were: "No Repairs Necesary".

2) Booted normally and ran SD 2.1 Smart Update. Recieved 53,100 lines in the syslog.

3) Ran Smart Update again and this time it added 56,300 lines to the syslog.


So, no change. Actually, first glance is that it gets worse each time it runs.

I also ran Disk Utility (10.4.4 OS X version) from another drive I booted from and the drive was ok. I think many users are not typically checking their system log files' size, and the asl.log is hidden away in /private/var/log.

If the asl.log file grows by ~ 18 Megabytes every time SD is run, that might not work well for me. Does the asl.log file get "recycled" every so often from the daily maintenance jobs? I ran DAILY and it didn't touch the asl.log file, although maybe that's because it wasn't very old. What is the criterion for DAILY to shrink the size of this file?

Another potential workaround -- is there a way to manually prune this asl.log file (which is just lines of text of these messages), say every several days, if it continues to grow like this? I'd hesitate to delete it or anything in /private/var unless I knew it were safe, and I suspect it is open for write during normal operations so doing something to it manually might cause some conflict if not done properly.

We're continuing to look into this; I'll let you know if we find a workaround.

Unfortunately, I don't really know what is going on here, but have a thought. Are any of you having these problems running Macaroni? Dale Meyn.

I don't think this has to do with Macaroni, Dale; there's clearly some case that's confusing the EA copying in the call we're using, which is making it log. We just have to try to work around that problem in the call.

It is, though, just (excessive) logging.

I did some research on this log file, asl.log, and it turns out that some other programs can result in huge output to asl.log. For instance, Adobe Acrobat, see

http://www.24help.info/adobe-acrobat...e-6.html?pp=10

This link also includes an example of how the terminal command call to syslog can be used to shrink the size of the log file. However this requires using root privileges (sudo), but if one mistypes or makes mistakes when doing this, it could have unpleasant consequences. So it's probably not something that the typical user (like me) wants to do routinely.

The normal cron maintenance routines should eventually prune these log files, I have read, but when I look inside the "daily" script it looks like it does this only after 21 days, during which literally hundreds (or thousands) of megabytes might be piling up. I was getting 18 Megabytes in asl.log with each backup.

By the way, is this happening only on my computer, or have you or others confirmed that this asl.log file under Tiger (I was using 10.4.4) grows by as much as many megabytes with each execution of SuperDuper (my disk being backed up is ~ 20 Gigagbytes in size)? My OS has never been modified except through the Apple Software Updates, it's version 10.4.4 right now. Recall that the asl.log file is in a hidden directory, /private/var/log.

We've seen this same problem, and can reproduce it, but not 18MB per backup, no.

I'll see if I can write a little script that can be used to trim the log automatically for you after a SD! run -- that will at least help until we can work around the call that's doing the logging.

Stand by.