Renamed files and directories

N.J. van der Horn (Nico) nico at vanderhorn.nl
Wed Feb 25 23:06:57 GMT 2009


Hmmm, right, IF and only IF you notice the rename at the source on time, 
you can do so at destination.
But in practise, I see its getting more and more impossible to keep up 
with the growing number of hosts.
Just keeping a DB with characteristics like checksum seems to be not the 
ultimate solution,
but at least in our case it would help a lot, as the biggest disaster is 
just massive renaming, or at top level.
Like you state, when the renamed file(s) is/are also modified, it is 
getting very hard to identify it/them again.
Basing on inode-number is not usable for all OS'es as far as i look at 
the problem.

Regards, Nico

Jamie Lokier schreef:
> David Howe wrote:
>   
>> N.J. van der Horn (Nico) wrote:
>>     
>>> What is the current status of both rename-patches ?
>>> Are there alternative measures ?
>>>
>>> Frequently users reorganise directories and files.
>>> Recently a directory of 40GB was renamed...
>>> It took 3 weeks to re-copy all over an ADSL-link.
>>>
>>> I have followed the last couple of years the postings,
>>> and realise it is not as easy as it seems.
>>> But the users do not understand this at all 8-(
>>>       
>> Hi all,
>>   Only recently joined the list - so haven't seen the last couple of
>> years worth of postings. Would there be a summary of the issues anywhere
>> handy? I have a customer who has issues similar to Nico regarding
>> directories being renamed with large amounts of storage needing deleting
>> and re-creating in a "stock" rsync install...
>>     
>
> There are methods to perform efficient updates of large numbers of
> files and a large amount of data, across simultaneous renames, copies
> and edits.  But that is the realm of "similarity detection indexing",
> which is beyond the scope of rsync.  At least with the present design,
> which doesn't use persistent indexing of any kind.  (This is a feature!)
>
> But when it's good enough to match files which have been renamed
> without edits and without changing modification time, it seems
> reasonable enough for rsync to have an option to detect those.  It's
> expensive, because it would have to scan the whole directory tree at
> both ends before transferring anything, and it would have to keep a
> little information about every file in RAM at once.  But imho it's a
> reasonable option to ask for, if someone wishes to write it.
>
> For myself, if I do a big rename of some directory tree, I try to
> remember to rename it manually at the destination too, before
> running rsync.
>
> -- Jamie
>   

-- 
Behandeld door / Handled by: N.J. van der Horn (Nico)
---
ICT Support Vanderhorn IT-works, www.vanderhorn.nl,
Kamer van Koophandel / Chambre of Commerce 24228233,
Voorstraat 55, 3135 HW Vlaardingen, The Netherlands,
Tel +31 10 2486060, Fax +31 10 2486061




More information about the rsync mailing list