Dave Kempe wrote:
> Most likely, to track moves you need to finish (or expand) the sha1
> hashing support introduced in the CVS version.
Another idea that was floating around about tracking moves was to keep
track of inodes on systems that have them. (ie, they are useless if user
is backing-up from an NFS or Samba mount.) I believe Dean Gaudet came up
with that one.
As I understand it, the benefit of tracking moves is that it uses less
disk space and bandwidth, no? (I haven't needed such a feature.)
Therefore, rdiff-backup will have to become smart enough to understand
that if I want file 'A' at time 30 days ago, it should first start with
file 'B' and then apply the appropriate reverse patches. Of course,
snapshots can muddle the waters here.
I think the cleanest way to handle that might be to introduce a special
type of increment (in addition to diffs, snapshots, missing, and dir)
called a 'rename' increment that points rdiff-backup in the correct
> Recovering dropped or lost backups is a good feature, however its
> important to preserve the certainty the current design gives about the
> destination being intact and accurate copy of the source at all(backup)
> points in time.
Yes, this is important.
> I hope you can contribute some code - if you need access to savannah I
> think I can set you up, please post patches to the mailing list to start
And try to test in as many situations as possible since these are big
changes (Mac <-> Linux, Windows/Cygwin, network shares, repository first
created under 1.1.x, etc.). I can test the Mac and Linux if you can't.
Andrew Ferguson - [email protected]
rdiff-backup-users mailing list at [email protected]
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki