severity 714234 grave
tags 714234 +upstream patch
forwarded 714234 http://sourceforge.net/p/dump/bugs/157/
quit

Hi,

This bug bit me, and meant that restoring an incremental backup failed :-(

My justification of severity is that broken backups result in data loss.

Ben Harris has analysed the bug and suggested a patch; you can find them
attached to the "forwarded" URL above, but I include them here:

"More analysis, building on sangamesh's work above:

The bug is that in findunreflinks(), the code for removing unreferenced
directories unconditionally calls deleteino() and then adds the node to
removelist even though this might already have been done. This causes a
panic in deleteino() because e_ino is zero, and causes an infinite loop
when anything tries to traverse removelist. The fix will be to skip
directories that are already scheduled for deletion.

And here's a possible patch to fix the problem. It assumes that if an
entry has e_ino == 0, that means it's already been passed to deletino()
and added to removelist. I think this is true. It's certainly the case
that all additions to removelist have e_ino == 0, so this should stop
the hangs and the panics from removino(). At worst, it will leave
spurious directories around after a restore."

I think a fix to this should be seriously considered for stable.

Regards,

Matthew
Index: restore/restore.c
===================================================================
RCS file: /cvsroot/dump/dump/restore/restore.c,v
retrieving revision 1.39
diff -u -r1.39 restore.c
--- restore/restore.c	22 Mar 2010 16:08:10 -0000	1.39
+++ restore/restore.c	1 Aug 2014 14:03:56 -0000
@@ -593,7 +593,7 @@
 					if (np->e_type == LEAF) {
 						removeleaf(np);
 						freeentry(np);
-					} else {
+					} else if (np->e_ino != 0){
 						np->e_flags |= TMPNAME;
 						deleteino(np->e_ino);
 						np->e_next = removelist;

Reply via email to