I just upgraded one of my test systems (client and server) from
rdiff-backup 1.0.0 to 1.0.4 (both with my --force-path-prefix patch
applied; perhaps at some point I'll try to reopen the discussion on
merging it upstream). While I can run new backups and increment them,
rollbacks are failing on an archive which was last used with
rdiff-backup 1.0.0, while they succeed otherwise.
The error which occurs is as follows:
Thu Jan 26 08:22:08 2006 Previous backup seems to have failed,
regressing destination now.
Thu Jan 26 08:22:08 2006 Client sending (0): ConnectionRequest:
regress.Regress with 1 arguments
Thu Jan 26 08:22:08 2006 Client sending (0): Path: /backup
Index: ()
Data: {'size': 4096L, 'uid': 104, 'perms': 493, 'inode': 3440942L,
'devloc': 2304L, 'nlink': 6, 'mtime': 1127988993, 'gid': 100, 'atime':
1138285316, 'type': 'dir', 'ctime': 1129615237}
Thu Jan 26 08:22:09 2006 Client received (0): 'ea'
Traceback (most recent call last):
File "/usr/bin/rdiff-backup", line 23, in ?
rdiff_backup.Main.Main(sys.argv[1:])
File "/usr/lib64/python2.3/site-packages/rdiff_backup/Main.py", line
286, in Main
take_action(rps)
File "/usr/lib64/python2.3/site-packages/rdiff_backup/Main.py", line
256, in take_action
elif action == "backup": Backup(rps[0], rps[1])
File "/usr/lib64/python2.3/site-packages/rdiff_backup/Main.py", line
300, in Backup
backup_final_init(rpout)
File "/usr/lib64/python2.3/site-packages/rdiff_backup/Main.py", line
397, in backup_final_init
checkdest_if_necessary(rpout)
File "/usr/lib64/python2.3/site-packages/rdiff_backup/Main.py", line
904, in checkdest_if_necessary
dest_rp.conn.regress.Regress(dest_rp)
File "/usr/lib64/python2.3/site-packages/rdiff_backup/connection.py",
line 445, in __call__
return apply(self.connection.reval, (self.name,) + args)
File "/usr/lib64/python2.3/site-packages/rdiff_backup/connection.py",
line 367, in reval
if isinstance(result, Exception): raise result
KeyError: 'ea'
Using --check-destination-dir to perform a rollback, as opposed to
relying on the one automatically done during a backup, results in an
uneventful regression, and later backups work successfully. If
--check-destination-dir emitted an error code for "checking unneeded"
*distinct* from other failure codes, I would probably just run it
locally to the server every time the rdiff-backup --server process is
started up and leave it at that; however, since the generic return
status 1 is used in this case (and since that same error code is used
for other failure cases as well), that's unworkable. (Personally, I
don't see why "checking unneeded" doesn't return success -- it seems
more useful that way than returning the same error code that's used for
serious issues which indicate unusability of the provided path).
