1 files changed, 0 insertions, 39 deletions
diff --git a/bugs/crashing-early-leads-to-assertion-error.mdwn b/bugs/crashing-early-leads-to-assertion-error.mdwn
deleted file mode 100644
index bda5d11..0000000
--- a/bugs/crashing-early-leads-to-assertion-error.mdwn
+++ /dev/null
@@ -1,39 +0,0 @@
-> `<SLi> liw, I run obnam backup for a small while (probably not
-> until even the first checkpoint) on a new repository, then ctrl-c
-> and say obnam fsck, I get AssertionError on assert 'key_size' in
-> ns_temp.get_metadata_keys().`
-
-Two things:
-
-* using `assert` is wrong in the code, it should raise an exception that
-  results in a humane error message
-* crashing before the first checkpoint should not result in an error
-  in the first place
-
---liw
-
-I've fixed the assertion in larch (it's now a more user-friendly
-error message). The crash still occurs, but I'm not sure if it's
-reasonable for Obnam to try to correct that. The same error may
-happen due to other reasons, and automatically fixing things is
-too likely to break things. So I'll leave the bug open, but take
-it off the 1.0 blockers list.
-
---liw
-
-I can reproduce this, by instrumenting the code so that
-it crashes after having backed up the first file. The error printed
-correctly identifies that the B-tree is broken. However, it is
-broken in a useful way. The B-tree is going to be so broken it
-does not have much useful information. There are some things that
-could be done (e.g., if no key size is stored in the B-tree, add
-one), but that only helps in specific cases, and I don't think
-that's useful enough. Thus, I think I will just give up for this
-kind of early corruption and have people start over. Sorry.
-(I'd fix this if I had lots of extra time, but I don't. If someone
-comes upon this bug later on, and makes a good patch, I'd be
-happy to accept it, of course.)
-
---liw
-
-[[done]]