Problem with DETS V9

[Valentin Micic]

Dear all,

If an opened DETS file (Version 9) was updated but not closed properly, what are the odds to have an appropriate MD5 digest?
To that end, what is the point of verifying MD5 digest before testing the "closed_properly" flag in dets_v9.erl?

The following is a fragment from dets_v9:check_file_header that illustrates the above:

 if
     FH#fileheader.cookie /= ?MAGIC ->
          {error, not_a_dets_file};
     FH#fileheader.type == badtype ->
          {error, invalid_type_code};
     FH#fileheader.version /= ?FILE_FORMAT_VERSION -> 
                {error, bad_version};
            FH#fileheader.has_md5 == true, 
            FH#fileheader.read_md5 /= FH#fileheader.md5 ->
                {error, not_a_dets_file}; % harsh but fair
     FH#fileheader.trailer /= FH#fileheader.eof ->
          {error, not_closed};
     FH#fileheader.closed_properly == ?CLOSED_PROPERLY ->
          {ok, true};
     FH#fileheader.closed_properly == ?NOT_PROPERLY_CLOSED ->
          {error, not_closed};
     HashBif == undefined ->
          {error, bad_hash_bif};
     true ->
      {error, not_a_dets_file}
 end,

I had a problem with MNESIA start-up... well, to cut a story short, I've been using mensia:activity with async_dirty access context on mnesia_frag module. 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. This change allowed MNESIA to repair corrupted dets files, and start without dumping the core.

Is the original testing order, as specified in above code fragment, there by design?

Valentin.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20040920/bf84ce33/attachment.htm>