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.
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
5 Posted by Forrest Corbett on 24 Aug, 2012 03:14 PM
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.
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.