Currently, the --one-file-system applies to both the source and destination and this is a problem.
In my source, I have a symlink pointing to a directory on another device which I would like to have copied. I thus use --copy-unsafe-links.
I also use --delete. This is dangerous because if there is a bug in my script, I would not like the destination to become suddenly / and deletion occurs on mounted network drives (granted, the machine would be toast, but the damage would be limited to the machine; not the corporate network).
If I make use of --one-file-system, the symlink at the source gets ignored. So I need a --one-file-system option that applies only to the destination, probably named something like --one-file-system-at-destination.
Could that be easily implemented? The following two options would be nice:
# Limit to one file system at the source.
# Limit to one file system at the destination.
Another approach would be to add --server-opt=OPT and --suppress-server-opt=OPT options to let the user tweak the list of options sent to the server. Then, for a push, --one-file-system-at-source would become -x --suppress-server-opt=-x and --one-file-system-at-destination would become --server-opt=-x . A pull would be the other way around. --server-opt would also be useful for things like --fake-super and --log-file that currently have to be stuffed in the --rsync-path .
There is a diff in the latest patches directory named remote-option.diff that implements a means of passing options to the remote rsync in a simple manner. This enables the ability to use "rsync -x --remote-option=--no-x" to have --one-file-system affect only the local side, and use "rsync --remote-option=-x" to have the option affect only the remote side. The new option also helps out with --fake-super, --log-file, and other similar options (as Matt noted).
Let me know what you think.
You can find the patch here:
And it applies to the latest nightly tar-file or git checkout.