OS X 10.6 (Snow Leopard) HFS+ File Compression

Tony tonyt57 at gmail.com
Sun Nov 1 18:57:56 MST 2009


Mike, thanks for the patch.  Will this patch be maintained in rsync- 
patches-3.0.6.tar.gz ?

On Oct 28, 2009, at 1:20 AM, Mike Bombich wrote:

> 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
>
> <rsync_3.0.6-hfs-compression_20091027.diff>
>
>
> 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/20091101/4fadf4a0/attachment.html>


More information about the rsync mailing list