Mon 20 Jun 2005 01:25:57 AM UTC, original submission:
this problem occurs when you have a pair of hardlinked files, which have been backed up at least once. then you modify the file and change the devloc without changing the inode.
this sort of thing can happen when you move the disk to another controller -- in my case it was happenning regularly because i was using LVM snapshot volumes and the snapshot device number is not fixed from one backup to the next.
here is a script which demonstrates the problem on linux using an ext2 image file, sudo, and two different loopback devices.
mkdir src || exit 1
dd if=/dev/zero of=src.img bs=1M count=2 || exit 1
mke2fs -qF -m 0 src.img || exit 1
sudo mount -o loop=/dev/loop3 src.img src || exit 1
echo hi >src/a || exit 1
ln src/a src/b || exit 1
rdiff-backup src dst || exit 1
sudo umount src
sudo mount -o loop=/dev/loop4 src.img src || exit 1
mv src/b src/c || exit 1
sleep 1; rdiff-backup src dst || exit 1
sleep 1; rdiff-backup src dst || exit 1
sudo umount src || exit 1
the second invocation of rdiff-backup produces a broken metadata file with two different DeviceLoc for the hardlinked files. the third (and any subsequent invocations) produce a bogus warning, but the problem is never resolved:
Warning: Attempt to rename over same inode: dst/rdiff-backup.tmp.1 to dst/c
i believe the fix is to treat devloc similar to inode in RORPath.__eq__ ... we're ignoring devloc currently, and that is broken... you can't compare inodes without comparing devices. the attached patch implements this idea.
-dean
|