Home → Questions →

Backup error: "Getting an extended attribute"

Admin Functions

• Remove

forrest

09 Aug, 2012 03:46 PM

My automatated backups on a new machine are getting this error when backing up via SMB. I'm only getting it on one file, but someone else I know with the same setup is getting it on several. I'm running 10.7.4 and CCC 3.4.6. I saw the other support message whre Mike replied "I'm pretty sure this is resolved in CCC 3.4.5".

No clue what's causing this. I've run CCC for many years on a different network with different computers. Not sure why out of both machines running it here, both are getting the same type of errors. We are backing up to the same server and close to the same location.

Thanks

PS. If the catpcha fails on this form, one has to re-enter their email address. Seems kinda odd.

CCC Report ID: 11152

CCC Report ID: 11153

1. Support Staff 2 Posted by Mike Bombich on 10 Aug, 2012 06:18 PM

   

   Hi Forrest:

   What kind of device is hosting the network share?

   08/08 18:50:05 rsync: get_xattr_data: lgetxattr("/Volumes/teams/Software Engineering/UI -UX/Forrest Corbett/Auto Backup/navigation icons.psd","com.apple.ResourceFork",7650) failed: Invalid argument (22)

   Errors like this, especially when isolated like this, usually suggest that there is a minor glitch in the filesystem entry for the affected file. Because it's on the destination, the easiest thing to do is to just delete the affected file and let CCC recopy it. If a Mac is hosting the sharepoint, you could use something like DiskWarrior to find and resolve the problem (Disk Utility rarely fixes these kinds of issues), but that's usually more work than just deleting the file.

   Let me know if that doesn't resolve the error on both Macs.

   Mike

   Admin Functions

   • Echo
   • Remove

2. 3 Posted by forrest on 10 Aug, 2012 10:33 PM

   

   The server is a Windows box... it's a DFS mount. I'm not really sure on the rest of the specifics.

   I deleted the local file, copied the remote file back and ran the backup again. Same issue.

   Admin Functions

   • Split
   • Remove

3. Support Staff 4 Posted by Mike Bombich on 10 Aug, 2012 11:36 PM

   

   Hi Forrest:

   I'm sorry, re-reading my response I can see how you might have thought that I meant for you to delete the file on the source. I meant that "because the file is on the destination" -- it's something that you can delete without affecting the original. Delete the file from the destination, then try it again. I believe the filesystem glitch is at the destination.

   It's also possible, though, that the server doesn't like extended attributes that are larger than 4KB. That's the norm for most filesystems, but resource forks are generally an exception and don't have any size limit. If you get the same errors after deleting those files from the destination, I'll put together a bundle of test files that we can add to the source to see if that's the issue.

   Mike

   Admin Functions

   • Echo
   • Remove

4. 5 Posted by Forrest Corbett on 24 Aug, 2012 03:14 PM

   

   Hi Mike,

   I deleted the file on the server and the problem for those specific files went away. Another person here did the same. However, over time the error occurs with other files. For me, it's been a couple weeks since I saw the error but for another person he sees it just about daily.

   It's a Windows server that connects to a DFS mount. Beyond that I don't know much about the server and don't have control over it.

   Any tips on resolving this issue?

   Thanks,
   Forrest

   Admin Functions

   • Split
   • Remove

5. Support Staff 6 Posted by Mike Bombich on 24 Aug, 2012 05:47 PM

   

   Hi Forrest:

   The problem is ultimately a filesystem issue on the server, e.g. the filesystem entry for the resource fork of these files is corrupted, or the filesystem is simply mishandling CCC's request to get the resource fork data from the file on the destination.

   You should be able to avoid these errors by backing up to a disk image on the network volume, rather than backing up directly to it. A disk image would create an "HFS+ oasis" on the SMB filesystem, so the resource forks would be entirely managed by an Apple-native filesystem. I usually recommend this anyway for the performance advantages, though in this case your data sets are pretty small so you won't see a huge gain there.

   I describe the setup procedure here:

   I want to back up my whole Mac to a Time Capsule or other network volume

   Mike

   Admin Functions

   • Echo
   • Remove

6. Mike Bombich closed this discussion on 20 Sep, 2012 04:58 AM.

Comments are currently closed for this discussion. You can start a new one.