Renamed files and directories
jamie at shareable.org
Mon Mar 2 16:49:15 GMT 2009
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.
More information about the rsync