Renamed files and directories

[Jamie Lokier]

N.J. van der Horn (Nico) wrote:
> >Right, but it has to be done in a separate pass if you're to compare
> >all files with each other, not just one destination file.  And you
> >need all the RAM, too.  It's like the worst case of "rsync -H".
> >  
> What I tried to point out is that when the DB is updated while it is 
> performing its work, it saves pass.
> Ofcourse the new run needs to check the DB before definately removing a 
> file or directory.

Please explain how this would work.

I don't see how a DB would save a pass, looking for renamed files
before transferring anything.

> >>Adding a DB to Rsync would give many more advantages, like:
> >
> >I vaguely remember a conscious decision not to expand rsync that much.
> >Keep the tool simple and stateless.  There are already other tools
> >which do the things you've described.
> >  
> Yes, KISS is good, but this expansion with a DB can be optionally 
> decided by a switch as well.
> So if you do not want it, just dont select the option.

The conscious decision was to keep the rsync tool source simple.
A switch does not remove it from the source code.

> Remember that the only wish I have is to avoid desastrous removal of
> files that are only moved.  I am not claiming that Rsync should
> cover any purpose, but as backup-tool my demand is reasonable.

Have you tried if the Unison program does what you want?
It maintains a DB at both ends.  Maybe it even handles renames.

-- Jamie