rsync - Jan 2017 - [Bug 2294] Detect renamed files and handle by renaming instead of delete/re-send

https://bugzilla.samba.org/show_bug.cgi?id=2294

--- Comment #27 from Wolfgang Hamann <wolfgang at maas-noten.de> ---
Hi,

I recently ran into the problem that a large file set got renamed and then
re-sent. I tried to fix after the fact, so I went the obvious way of comparing
sizes and modtimes on the destination and calculate checksums for potential
matches. I would have preferred to use a list of inode numbers and files for
the old and new file sets instead...

So I wonder whether a different approach to the problem could make sense:
a) the filelist contains inode numbers, and after a successful rsync, a file is
generated in the target dir listing inodes and names of all files transferred
b) when receiving to the same dir, if a target file does not exist, the inode
in the filelist is used to look up the previous filename. If it exists and
matches in size and modtime, it could be hardlinked. Deleting files from the
target that are no longer in the source would take care of the old file. When
the sync is completed without error, the list of inodes and file names would be
updated
c) when receiving in link-dest mode, the file in the old dir would be consulted
for a potential match, and the new list would be created in the target dir

Of course this only makes sense if inode numbers are reliable, as on all
standard local file systems or nfs. I do not know whether the new storage
arenas preserve inodes. It is obvious that the same inode may appear more than
once in a source file set

Regards
Wolfgang

-- 
You are receiving this mail because:
You are the QA Contact for the bug.