I wouldn't blame the rsync team for not wanting to maintain it, it's a
pretty narrow-scope patch affecting only one OS. I'm pretty motivated
to keep it up, though, so I'll repost my patches to this list when I
update them. I'll probably get it updated to 3.1.0 in the next month
or so.
Mike
On Nov 1, 2009, at 7:57 PM, Tony wrote:
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
--
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
--
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
