<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I wouldn't blame the rsync team for not wanting to maintain it, it's a pretty narrow-scope patch affecting only one OS. &nbsp;I'm pretty motivated to keep it up, though, so I'll repost my patches to this list when I update them. &nbsp;I'll probably get it updated to 3.1.0 in the next month or so.<div><br></div><div>Mike<br><div><br><div><div>On Nov 1, 2009, at 7:57 PM, Tony wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>Mike, thanks for the patch. &nbsp;Will this patch be maintained in&nbsp;rsync-patches-3.0.6.tar.gz ?</div><br><div><div>On Oct 28, 2009, at 1:20 AM, Mike Bombich wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">HFS compression can be preserved as long as the relevant xattr(s) and flags on those files are preserved. &nbsp;A compressed file has the compressed data in a hidden xattr (com.apple.decmpfs if &lt; 4Kb, com.apple.ResourceFork if more), and has the UF_COMPRESSED flag set (decimal 40). &nbsp;When rsync encounters a file like this, it should ignore the data fork of the file, which will appear to contain normal, uncompressed data. &nbsp;It should also pass a special flag to the xattr calls to expose the decmpfs xattrs.<div><br></div><div>I've already&nbsp;<a href="http://www.bombich.com/software/opensource/rsync_3.0.6-bombich_20090825.diff">implemented this in rsync</a>&nbsp;(3.0.6), I just hadn't taken the time to craft the HFS-compression-specific changes into a patch. &nbsp;I did that this evening and attached it below. &nbsp;These are changes against the 3.0.6 base, plus the crtimes, fileflags, and backup-dir-dels patches. &nbsp;It should work, at minimum, against the 3.0.6 base plus the fileflags patch (that patch is required).</div><div><br></div><div>Let me know if it doesn't work for you, it's entirely possible that I overlooked something in the extraction.</div><div><br></div><div>Mike</div><div><br><div></div></div></div><span>&lt;rsync_3.0.6-hfs-compression_20091027.diff&gt;</span><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><br><div><div><br></div><div>On Oct 27, 2009, at 11:08 PM, Matt McCutchen wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Tue, 2009-10-27 at 23:38 -0400, Tony wrote:<br><blockquote type="cite">When rsync 3.0.6 copies files with HFS+ File Compression, the new &nbsp;<br></blockquote><blockquote type="cite">extended attribute decmpfs is not preserved, and the UF_COMPRESSED &nbsp;<br></blockquote><blockquote type="cite">flag is not set on the destination and the destination file is not &nbsp;<br></blockquote><blockquote type="cite">compressed.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I examined the destination file as described in ars technica &nbsp;(with ls &nbsp;<br></blockquote><blockquote type="cite">and xattr from a 10.5 Leopard boot), and the compressed data is moved &nbsp;<br></blockquote><blockquote type="cite">from the resource fork to the data fork, and the extended attributes &nbsp;<br></blockquote><blockquote type="cite">'@' are removed from the file.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">As far as I know, only ditto in 10.6 can handle HFS+ File &nbsp;<br></blockquote><blockquote type="cite">Compression. &nbsp;(I even tested a 'clone' with disk utility (file copy, &nbsp;<br></blockquote><blockquote type="cite">not block), and it also failed (block copy, of course works).<br></blockquote><br>Rsync is just reading and writing files via the filesystem API; it has<br>no access to any of the flags or xattrs used to implement the<br>compression.<br><br>I guess the filesystem doesn't compress new files by default. &nbsp;If it had<br>an API to request compression, rsync could use that API when writing the<br>destination files. &nbsp;Unfortunately, the API ditto is using appears to be<br>private to Apple. &nbsp;See the post from brkirch beginning "The first thing<br>that I tried to do" on this page:<br><br><a href="http://www.macosxhints.com/article.php?story=20090902223042255">http://www.macosxhints.com/article.php?story=20090902223042255</a><br><br>So anyone interested in making rsync compress the destination files<br>would probably have to copy the relevant code from afsctool. &nbsp;This could<br>be shared as a patch; I feel quite sure it would not be adopted in the<br>main version of rsync.<br><br>-- <br>Matt<br><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></blockquote></div><br></div>-- <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></blockquote></div><br></div></div></body></html>