OS X 10.6 (Snow Leopard) HFS+ File Compression

[Mike Bombich]

HFS compression can be preserved as long as the relevant xattr(s) and  
flags on those files are preserved.  A compressed file has the  
compressed data in a hidden xattr (com.apple.decmpfs if < 4Kb,  
com.apple.ResourceFork if more), and has the UF_COMPRESSED flag set  
(decimal 40).  When rsync encounters a file like this, it should  
ignore the data fork of the file, which will appear to contain normal,  
uncompressed data.  It should also pass a special flag to the xattr  
calls to expose the decmpfs xattrs.

I've already implemented this in rsync (3.0.6), I just hadn't taken  
the time to craft the HFS-compression-specific changes into a patch.   
I did that this evening and attached it below.  These are changes  
against the 3.0.6 base, plus the crtimes, fileflags, and backup-dir- 
dels patches.  It should work, at minimum, against the 3.0.6 base plus  
the fileflags patch (that patch is required).

Let me know if it doesn't work for you, it's entirely possible that I  
overlooked something in the extraction.

Mike



On Oct 27, 2009, at 11:08 PM, Matt McCutchen wrote:

> On Tue, 2009-10-27 at 23:38 -0400, Tony wrote:
>> When rsync 3.0.6 copies files with HFS+ File Compression, the new
>> extended attribute decmpfs is not preserved, and the UF_COMPRESSED
>> flag is not set on the destination and the destination file is not
>> compressed.
>>
>> I examined the destination file as described in ars technica  (with  
>> ls
>> and xattr from a 10.5 Leopard boot), and the compressed data is moved
>> from the resource fork to the data fork, and the extended attributes
>> '@' are removed from the file.
>>
>> As far as I know, only ditto in 10.6 can handle HFS+ File
>> Compression.  (I even tested a 'clone' with disk utility (file copy,
>> not block), and it also failed (block copy, of course works).
>
> Rsync is just reading and writing files via the filesystem API; it has
> no access to any of the flags or xattrs used to implement the
> compression.
>
> I guess the filesystem doesn't compress new files by default.  If it  
> had
> an API to request compression, rsync could use that API when writing  
> the
> destination files.  Unfortunately, the API ditto is using appears to  
> be
> private to Apple.  See the post from brkirch beginning "The first  
> thing
> that I tried to do" on this page:
>
> http://www.macosxhints.com/article.php?story=20090902223042255
>
> So anyone interested in making rsync compress the destination files
> would probably have to copy the relevant code from afsctool.  This  
> could
> be shared as a patch; I feel quite sure it would not be adopted in the
> main version of rsync.
>
> -- 
> Matt
>
> -- 
> Please use reply-all for most replies to avoid omitting the mailing  
> list.
> To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/rsync/attachments/20091028/2b903ba8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rsync_3.0.6-hfs-compression_20091027.diff
Type: application/octet-stream
Size: 33097 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/rsync/attachments/20091028/2b903ba8/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/rsync/attachments/20091028/2b903ba8/attachment-0001.html>