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.] -- 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
