[patch] NFSv4/ZFS ACLs

f-rsync at media.mit.edu f-rsync at media.mit.edu
Sat Jul 21 14:42:44 MDT 2012


If you're thinking about changing the way attrs work, here's a
question for you.  I just recently started trying to use them for the
first time, in backing up a Windows host via a wrapper script that
runs the remote rsync under Cygwin on the Windows side, by mounting
the source disk as a VSS snapshot as long as the Windows-side rsync is
running.  This enables dirvish, running on a Linux host, to actually
be able to read all the files in the Windows filesytem without tripping
over Windows file locks.  The wrapper must call rsync directly, rather
than setting things up and then letting a separate network connection
call rsync, because apparently the VSS mapping is only valid for the
duration of the invoking program.  (Search for tb-rsync-vss.)

But that wrapper script does not (yet) have a way to pass any args
to the rsync that it calls internally, yet to actually preserve file
metadata from the Windows side, I need to invoke --fake-super on the
Windows side via --rsync-path.  So while the wrapper script wants me
to do "--rsync-path=where-rsync-is-on-the-windows-side" it can't cope
with "--rsync-path=where-rsync-is-on-the-windows-side --fake-super";
its argument parsing doesn't expect additional args to accompany its
version of rsync-path, and it has no way to specify remote-side-only
extra args to rsync.  [In fact, it parses various args "by hand" out
of a single string that's passed to the script by abusing the final
"path" argument from the invoking rsync, and --rsync-path is one.]

I've asked the maintainer of that script to see if he can add that
functionality, which shouldn't be hard once he gets to it.  But it's
peculiar that rsync does it this way in the first place.  I understand
that one wants individual control of which end of the connection is
(or is not) doing --fake-super, but wouldn't it be somewhat more
logical to take this out of --rsync-path and instead make something
like --local-fake-super and --remote-fake-super instead, so the args
could be passed around in a consistent fashion?  Also, by explicitly
mentioning "local" in "fake-super", you'd be warning people that
they're only looking at half the story; I see various cries for help
on the net where people couldn't get --fake-super to work because they
didn't read that section of the manpage carefully enough to realize
that they needed to specify --fake-super inside --rsync-path instead
of or in addition to its use in the normal set of args to the local
rsync.

In fact, --fake-super seems to be a very peculiar exception to the way
rsync args are handled---so peculiar that I hadn't noticed it worked
that way before I had to use it, and the script author had no idea
that the remote rsync could be getting args that way, either, until I
pointed him at that particular manpage section.

Of course, making such a change would still have to honor the existing
args for backward compatibility in existing scripts.  *sigh*...

P.S.  I'm using --fake-super on the sending side in the first place
because, in part, there are many instances of unknown users and groups
which Cygwin is mapping into -1, which can't be handled on the Linux
side of the connection and cause rsync to complain.  (And I value
those complaints!  They warned me I was doing something wrong.)  But
in general, since I'm trying to actually back up the Windows side, I'd
really like to hang onto even non-POSIX metadata, so it seems like I
want --fake-super on the sending side and --fake-super --xattrs --acls
on the receiving side to run the backup.  Correct?  [My normal backups
of other Linux hosts don't bother with --fake-super on either end.]


More information about the rsync mailing list