<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div></div><div><br><div><br><div><div>On Jul 1, 2010, at 6:16 AM, Robert DuToit wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi Mike and All,<br><br>I have been doing some research on the damaged HFS compressed files and found some interesting clues. Looking at mike's patch so far I can't find any reason for the damage (I have to learn more C language ) but what still seems odd is that the damage only happens when copying the whole /usr directory or /usr/bin /usr/share. Individually copying one of the original files does not create the damaged file.<br><br>Pertaining to the use of Mike's patch on OSX 10.6.4 copying /usr/bin and resulting damaged files<br><br>In /usr/bin/ I found that the originals of the damaged files are different from the other "normal" exec files. In this case I am looking at the "find" exec.<br><br>If I copy "find" from /usr/bin/ to the desktop via finder copy, it is changed to resemble the "normal" execs. And indeed if I replace the original with this copy in /usr/bin and copy /usr/bin with patched rsync, the copied "find" is no longer damaged!<br><br>So it appears that when the patched rsync encounters one of these "odd" files ( and only when copying the whole /usr/bin/ directory containing them ) it causes the problem.<br><br>Here are results using hfsdebug (sorry about the amount of reading!)<br><br><br>####################<br>original "file" exec - works ok but different from other execs in /usr/bin. ( It shows the com.apple.decmpfs flag and data is stored in Resource Fork)<br><br> flags = 0000000000000110<br> . File has extended attributes.<br><br> # Data Fork<br> logicalSize = 0 bytes<br> # Resource Fork<br> logicalSize = 101755 bytes<br> totalBlocks = 25<br><br># Attributes<br> <Attributes B-Tree node = 6754 (sector 0x294b0)><br> # Attribute Key<br> keyLength = 46<br> pad = 0<br> fileID = 3904426<br> startBlock = 0<br> attrNameLen = 17<br> attrName = com.apple.decmpfs<br> # Inline Data<br> recordType = 0x10<br> reserved[0] = 0<br> reserved[1] = 0<br> attrSize = 16 bytes<br> attrData = 66 70 6d 63 04 00 00 00 b0 a0 03 00 00 00 00 00 <br> f p m c<br><br> compression magic = cmpf<br> compression type = 4 (resource fork has compressed data)<br> uncompressed size = 237744 bytes<br><br>####################<br>A normal exec "find" in /usr/bin/ ( data stored in # Data Fork so it is showing as uncompressed in finder)<br><br> flags = 0000000000000010<br><br> # BSD Info<br> ownerID = 0 (root)<br> groupID = 0 (wheel)<br> = 0<br> # Data Fork<br> logicalSize = 147680 bytes<br> totalBlocks = 37<br> clumpSize = 2445<br><br> # Resource Fork<br> logicalSize = 0 bytes<br><br><br>####################<br>the original "file" exec now copied via patched rsync within the whole /usr/bin directory (Note: no data in Data Fork or Resource Fork)<br><br>First note that the xattrs show up ( not supposed to when seen from 10.6)<br><br>robert-dutoits-macbook-pro:~ astrid$ xattr -l /Users/astrid/Desktop/copied_bin_test/bin/file <br>com.apple.ResourceFork: <br>com.apple.decmpfs:<br><br>and the hfsdebug report:<br><br> flags = 0000000000000110<br> . File has extended attributes.<br><br> # Data Fork<br> logicalSize = 0 bytes<br> # Resource Fork<br> logicalSize = 1 bytes<br> totalBlocks = 1<br><br> # Attributes<br> <Attributes B-Tree node = 5258 (sector 0x23730)><br> # Attribute Key<br> keyLength = 46<br> startBlock = 0<br> attrNameLen = 17<br> attrName = com.apple.decmpfs<br> # Inline Data<br> recordType = 0x10<br> reserved[0] = 0<br> reserved[1] = 0<br> attrSize = 1 bytes<br> attrData = 04 <br><br> compression magic = .<br> compression type = 44000000 (?)<br> uncompressed size = 1224979098644812920 bytes<br><br><br>####################<br><br>I can't put this all together yet but if anyone can see what is going on I would much appreciate it. What throws me though it that the damage only happens when copying the whole /usr/bin/ directory…<br><br>Again - this is rsync 3.0.6 patched with fileflags, crtimes and Mike's hfs patch.<br><br>Thanks, Rob<br><br><br><br><br><br>On Jun 25, 2010, at 4:03 PM, Mike Bombich wrote:<br><br><blockquote type="cite">Can you share the steps required to reproduce this? I've seen two reports of this but have not been able to reproduce it myself, and the users that reported it also could not reproduce it.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Mike<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Jun 25, 2010, at 5:16 AM, Robert DuToit wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Hi All,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I ran xattr on it and <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">robert-dutoits-macbook-pro:~ astrid$ xattr -l /Volume/Snowy/usr/bin/file<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">com.apple.ResourceFork: <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">com.apple.decmpfs: <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">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. <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">There are some threads about this, specifically bugs in the Snow Leopard causing this very thing to happen. <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">There is a tool someone created for scanning for these damaged files at:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://www.charlessoft.com/find_sl_damaged_files.zip">http://www.charlessoft.com/find_sl_damaged_files.zip</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">After running rsync 3.0.6 , with patches for hfs+, it reports <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">/Volume/Snowy/usr/bin/chudRemoteCtrl appears to be damaged<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">/Volume/Snowy/usr/bin/chumAddRights appears to be damaged<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">/Volume/Snowy/usr/bin/ci appears to be damaged<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">/Volume/Snowy/usr/bin/bzip2recover appears to be damaged<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">/Volume/Snowy/usr/bin/file appears to be damaged<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">/Volume/Snowy/usr/bin/xed appears to be damaged<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">These same files are fine on the source volume.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Anyone know why this is happening? The hfs+ compressed files are otherwise handled perfectly using Mike's patch.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Thanks Rob<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">-- <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Please use reply-all for most replies to avoid omitting the mailing list.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">To unsubscribe or change options: <a href="https://lists.samba.org/mailman/listinfo/rsync">https://lists.samba.org/mailman/listinfo/rsync</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Before posting, read: <a href="http://www.catb.org/~esr/faqs/smart-questions.html">http://www.catb.org/~esr/faqs/smart-questions.html</a><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><br>-- <br>Please use reply-all for most replies to avoid omitting the mailing list.<br>To unsubscribe or change options: <a href="https://lists.samba.org/mailman/listinfo/rsync">https://lists.samba.org/mailman/listinfo/rsync</a><br>Before posting, read: <a href="http://www.catb.org/~esr/faqs/smart-questions.html">http://www.catb.org/~esr/faqs/smart-questions.html</a><br></div></blockquote></div><br></div></div></div></body></html>