HFS+ compression support [was Re: Backing up resource forks]

Wayne Davison wayned at samba.org
Thu Mar 17 12:18:25 MDT 2011

On Wed, Mar 16, 2011 at 11:52 AM, Mike Bombich <mike at bombich.com> wrote:

> The receiver should probably just exit with RERR_UNSUPPORTED if the
> --protect-decmpfs option is used and the destination filesystem doesn't
> support it.  I was hoping to provide failover to decompression for the
> --hfs-compression option, though, which is what the use of the compat flags
> offers.

Yeah, I was thinking about that more, and will try to work something out.
If I don't come up with something, I'll reserve this bit in the compat flags
for hfs and put that back in.

Also, this same block of code should be present in x_lstat and x_fstat.

Good point.

I'm not clear why we call itemizing() here

Because we want to know about each change that is made in the destination
tree, even when a file is being hard-linked instead of copied.  It needs to
be itemized against what was there before, though, so that it shows things
like if the hard-linked file is new, or if the changed file has a different
time, or what not.  The prior file at that point (if there was one) may not
have been already hard-linked into the new hard-link cluster.  Your original
change (that set statret) broke the testsuite (it made a new file itemized
as non-new) and my leaving the re-stat in broke other itemizing info.  I've
removed the changes from hlinks.c.

As for the extra xattr setting on hard-linked files, I think changing this
line in receiver.c:

    if (preserve_xattrs && iflags & ITEM_REPORT_XATTR && do_xfers)

To this:

    if (preserve_xattrs && BITS_SETnUNSET(iflags, ITEM_REPORT_XATTR,
ITEM_XNAME_FOLLOWS) && do_xfers)

Should avoid the extra xattr-setting on a hard-linked file.  I've updated
the git version of the patch with your latest fixes and this change.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/rsync/attachments/20110317/ad778196/attachment.html>

More information about the rsync mailing list