#232 closed defect (released)
Flint database can be corrupted if metadata is written on its own first
| Reported by: | Richard Boulton | Owned by: | New Bugs |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Backend-Flint | Version: | SVN trunk |
| Severity: | normal | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | Operating System: | All |
Description
I've found a sequence of events which lead to a corrupt database being produced.
Attaching a patch to the testsuite which reproduces this.
Attachments (1)
Change History (3)
by , 16 years ago
comment:1 by , 16 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
This was caused by a failure to update the revision in the Flinttable_base object when commit() or cancel() was called on a lazy table which hadn't yet been created, so the newly created base file was being created at revision 0 (or whatever revision the database was originally opened at). The "corruption" resulting from this was only visible until the first commit, because after a commit, the new base file for the table was set to the correct revision number.
If a database was corrupted due to this bug, removing the newly created (and presumably empty) base file and DB file should produce a valid database.
Fixed in HEAD in SVN revision 10072.
Patch to testsuite to reproduce bug