rsync and hfs+ compressed files damaged
rdutoit at comcast.net
Fri Jun 25 04:16:55 MDT 2010
I have been using rysnc 3.0.6 with Mike's rsync_3.0.6-hfs-compression_20091027.diff patch (as well as the standard osx patches) with good results. I discovered that clones done on 10.6 using this rsync cause some executable files ( the ones that are mostly compressed this way on osx ) to be damaged.
I did a test twice and indeed a handful of them are damaged. They all appear to be in /Volume/Snowy/usr/bin and/or /Volume/Snowy/usr/share.
I ran xattr on it and
robert-dutoits-macbook-pro:~ astrid$ xattr -l /Volume/Snowy/usr/bin/file
These attributes are supposed to be hidden when on 10.6. The files have 0 bytes to appear to be compressed but can not be un-compresed. I tried file on the clone and it doesn't work. Someone else reported du not working so there are some pretty basic files damaged. This appears to be the same issue that happens with some people when installing Snow Leopard fresh - some execs are damaged in this way.
There are some threads about this, specifically bugs in the Snow Leopard causing this very thing to happen.
There is a tool someone created for scanning for these damaged files at:
After running rsync 3.0.6 , with patches for hfs+, it reports
/Volume/Snowy/usr/bin/chudRemoteCtrl appears to be damaged
/Volume/Snowy/usr/bin/chumAddRights appears to be damaged
/Volume/Snowy/usr/bin/ci appears to be damaged
/Volume/Snowy/usr/bin/bzip2recover appears to be damaged
/Volume/Snowy/usr/bin/file appears to be damaged
/Volume/Snowy/usr/bin/xed appears to be damaged
These same files are fine on the source volume.
Anyone know why this is happening? The hfs+ compressed files are otherwise handled perfectly using Mike's patch.
More information about the rsync