Problem with DETS V9

[hasse@REDACTED]

[Valentin Micic:]
> If an opened DETS file (Version 9) was updated but not closed
> properly, what are the odds to have an appropriate MD5 digest? 
> 
> Somehow, after shutting MNESIA down, we ended up with a bunch of
> corrupted DETS files. MNESIA refused to start because of the
> above-mentioned issue, and the only way to fix it was to change the
> evaluation order in DETS_V9 module.
> 
> Is the original testing order, as specified in above code fragment,
> there by design?

The MD5 digest only captures some hundred bytes of metadata that must
never be wrong. If a Dets file has a bad MD5 digest it means that the
beginning of the file has been changed somehow, and that there is a
risk that objects have been compromised as well. When it happens it's
better to copy the file from some other Mnesia node than trying to
repair the file.

A side-note. Dets has no support for detecting compromised data in
case the MD5 digest is OK: if binary_to_term fails for some object
then 'bad_object' is returned, but if binary_to_term succeeds it could
still be the case that the object is corrupt. For instance, the atom
'a' could have changed to 'b' without Dets ever discovering it. So far
this behaviour hasn't been considered a real problem since the
contents of files are "never" compromised.

Best regards,

Hans Bolinder, Erlang/OTP