Renamed files and directories

N.J. van der Horn (Nico) nico at vanderhorn.nl
Thu Feb 26 09:21:33 GMT 2009


The highest speed and efficiency is to only observe time and size as 
then just a stat-call is needed.
But in more complex situations you have to take also the checksum, 
inode-number, etc into account.
In previous posts there were many ideas to cope with this. As rsync is 
state-less regarding the filesystem,
it needs to be extended by a DB to hold the previous state of the 
observed filesystem.
The DB can provide quickly files on many aspects, eg find a file by 
checksum or other characteristic
that is not possible to ask from a standard filesystem without doing a 
full scan first.

The worse case problem by tackling renamed files and directories is when 
they are not only moved
or renamed, but when they are also changed in contents.

You probably noticed Henri's reply, he pointed to link-backup:

    This URL has a links to Link-Backup and LSync :
    http://connect.homeunix.com/lbackup/about#alternatives_to_lbackup

    The LSync project has integrated with Link-Backup if you are
    interested.
    otherwise just jump directly to the Link-Backup project.

It is a big python script, but not easy to integrate in my current setup.


Nico

Jamie Lokier schreef:
> N.J. van der Horn (Nico) wrote:
>   
>> 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.
>>     
>
> True, inode number is not usable for all filesystems on unix either.
> But it works well enough for most of them.
>
> Without trusting inode numbers from run to run, what can you do?
> Reading the content of all files to calculate the checksums before
> starting will take a very long time in many cases.
>
> -- 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