Add --no-tweak-hlinked, etc.
hashproduct+rsync at gmail.com
Fri Sep 1 21:48:28 GMT 2006
Dear rsync people,
Usually, if the receiving rsync finds a destination file that passes
the quick check with the source file but differs in attributes, the
receiving rsync will change the attributes. This is undesirable when
the destination is an incremental backup containing files hard-linked
from older backups.
Thus, I propose an option --no-tweak-hlinked to tell the receiving
rsync not to change the attributes of an existing destination file
with more than one link. Instead, rsync would copy the file and move
the copy over the link to the shared original.
I'm thinking about how best to implement this. I would love to use
copy_file(fname, fname). That opens the file, deletes it, and then
creates a new one by the same name, so it works; however, if rsync is
interrupted, data is lost. Using an rsync-style temporary file would
be good, but copy_file would have to be changed.
It occurs to me that --copy-dest local copies should probably also use
a temporary file so that replaces are atomic. However, get_tmpname is
currently private to receiver.c. That brings up another good point:
maybe the receiver should perform both --copy-dest and
--no-tweak-hlinked local copies since they might hold up the pipeline
if done in the generator. But then the generator has to somehow
indicate the source of the local copy to the receiver. In fact, the
generator has collected a lot of logic unrelated to its main purpose
(sending the block checksums of basis files) that could be moved to
the receiver to avoid holding up the pipeline. And suddenly we're
talking about major changes to rsync. I think they would constitute
an improvement, but I doubt anyone wants to undertake them now.
More information about the rsync