--detect-renamed question

[Greg Siekas]

Matt,

That was too quick!  I think --trust-move is a really good thing and  
I'll test it out soon.

Some thoughts on all this now that I've had my caffeine this morning.

It would take one very crafty user to delete a file and create one  
with the same name, mtime, and size.  The only issue I can see is if   
there were 2 files with the same name, mtime, and size but different  
data.  Highly unlikely but still possible, right?  Let's call these  
files fileA and fileB.  If fileA is deleted and fileB is copied to  
another directory, what happens?  Rsync would hard link the fileA as  
the new fileB when using --trust-move.  We end up with fileA and  
fileB on the destination with fileB and fileB on the source.

So, how do we fix this situation?  Is there a way to check for  
duplicate entries?  If rsync checks if the file it's about to hard  
link is a non-unique file, (same name, mtime, size as another file)  
then it should copy from the source fileB instead of hard linking  
from the deleted fileA.  Does this make sense?  It would require  
rsync to have a complete scan of the source prior to doing anything.

This should help those situations where someone does an upper level  
directory move with lots of files and data underneath.  I recall  
someone else was asking about this on the list.

Greg


On Oct 12, 2007, at 6:43 PM, Matt McCutchen wrote:

> On 10/12/07, Greg Siekas <radius13a at mac.com> wrote:
>> The other option I thought of was to only do the move when the mtime,
>> size, and filename match.   Not really a 'detect-renamed' but a
>> 'detected-moved' type operation.
>
> That's a good idea, and easy to implement too!  I have improved the
> patch (attached) to provide separate --trust-rename and --trust-move
> options.  Wayne, please consider adding this to patches/ .
>
> Matt
> <trust-rename.diff>