Shirt Pocket Discussions  
    Home netTunes launchTunes SuperDuper! Buy Now Support Discussions About Shirt Pocket    

Go Back   Shirt Pocket Discussions > SuperDuper! > General

Reply
 
Thread Tools Rate Thread Display Modes
  #1  
Old 03-09-2006, 01:00 PM
priller priller is offline
Registered User
 
Join Date: Dec 2005
Posts: 10
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?
Reply With Quote
  #2  
Old 03-09-2006, 01:08 PM
dnanian's Avatar
dnanian dnanian is offline
Administrator
 
Join Date: Apr 2001
Location: Weston, MA
Posts: 14,923
Send a message via AIM to dnanian
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...
__________________
--Dave Nanian
Reply With Quote
  #3  
Old 03-12-2006, 10:17 PM
priller priller is offline
Registered User
 
Join Date: Dec 2005
Posts: 10
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

Last edited by priller; 03-12-2006 at 10:21 PM. Reason: Additional Info
Reply With Quote
  #4  
Old 03-12-2006, 10:33 PM
dnanian's Avatar
dnanian dnanian is offline
Administrator
 
Join Date: Apr 2001
Location: Weston, MA
Posts: 14,923
Send a message via AIM to dnanian
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...
__________________
--Dave Nanian
Reply With Quote
  #5  
Old 03-13-2006, 01:27 AM
sdsl sdsl is offline
Registered User
 
Join Date: Dec 2005
Posts: 73
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?
Reply With Quote
  #6  
Old 03-13-2006, 07:32 AM
dnanian's Avatar
dnanian dnanian is offline
Administrator
 
Join Date: Apr 2001
Location: Weston, MA
Posts: 14,923
Send a message via AIM to dnanian
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.)
__________________
--Dave Nanian
Reply With Quote
  #7  
Old 03-13-2006, 08:03 AM
priller priller is offline
Registered User
 
Join Date: Dec 2005
Posts: 10
Quote:
Originally Posted by dnanian
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...
These have all been Smart Updates. The first one was 5,000 lines. The next 3 were all 56,000 lines.
Reply With Quote
  #8  
Old 03-13-2006, 08:17 AM
dnanian's Avatar
dnanian dnanian is offline
Administrator
 
Join Date: Apr 2001
Location: Weston, MA
Posts: 14,923
Send a message via AIM to dnanian
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.
__________________
--Dave Nanian
Reply With Quote
  #9  
Old 03-13-2006, 10:58 AM
priller priller is offline
Registered User
 
Join Date: Dec 2005
Posts: 10
Quote:
Originally Posted by dnanian
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.
Reply With Quote
  #10  
Old 03-13-2006, 11:17 AM
sdsl sdsl is offline
Registered User
 
Join Date: Dec 2005
Posts: 73
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.

Last edited by sdsl; 03-13-2006 at 11:29 AM.
Reply With Quote
  #11  
Old 03-13-2006, 11:42 AM
dnanian's Avatar
dnanian dnanian is offline
Administrator
 
Join Date: Apr 2001
Location: Weston, MA
Posts: 14,923
Send a message via AIM to dnanian
We're continuing to look into this; I'll let you know if we find a workaround.
__________________
--Dave Nanian
Reply With Quote
  #12  
Old 03-14-2006, 11:47 AM
DaleMeyn DaleMeyn is offline
Registered User
 
Join Date: Feb 2006
Location: Stafford county, VA
Posts: 53
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.
Reply With Quote
  #13  
Old 03-14-2006, 11:56 AM
dnanian's Avatar
dnanian dnanian is offline
Administrator
 
Join Date: Apr 2001
Location: Weston, MA
Posts: 14,923
Send a message via AIM to dnanian
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.
__________________
--Dave Nanian
Reply With Quote
  #14  
Old 03-14-2006, 12:35 PM
sdsl sdsl is offline
Registered User
 
Join Date: Dec 2005
Posts: 73
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.
Reply With Quote
  #15  
Old 03-14-2006, 12:39 PM
dnanian's Avatar
dnanian dnanian is offline
Administrator
 
Join Date: Apr 2001
Location: Weston, MA
Posts: 14,923
Send a message via AIM to dnanian
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.
__________________
--Dave Nanian
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -4. The time now is 05:37 PM.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2024, vBulletin Solutions, Inc.