Subject: How to recover my corrupt mbx INBOX?

From: Gus Teschke <[email-masked]>
Date: Mon, 14 May 2001 18:49:08 -0400

Hi c-client folks,
I was using Netscape 4.7 on Solaris 2.7 to connect to an old UW IMAP
server on Solaris 2.6 (IMAP4rev1 v11.241, no NFS), when I received this
message when trying to use my mbx-formatted INBOX.

   The current command did not succeed.
   The mail server responded:
   SELECT failed: unable to parse internal header at 101590395: ct.p

I've been unable to get UW to open the file.
What have I tried?
1. Install the latest UW IMAP server, and use it to open the INBOX.
        Same error.
2. Use a Windows version of Netscape.  Same error.
3. mbxcopy, icat, and mbxcvt (to Unix format).
        ?EXAMINE failed: Unable to parse internal header at 101590395:
ct.py

Is there another tool I might use to recover this
111,303,641 byte INBOX?

Strings de-mbxes the file,
    strings INBOX > inbox.mangled
but is any text lost? The stringed file's tail is not the same
as the mbx file, and that makes me suspicious.

Thanks for any help,
Gus

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Mon, 14 May 2001 16:07:34 -0700 (PDT)

This is in the newest FAQ, but I haven't yet published that version yet.
Sorry.  Here's the question and it's associated answer.  I'll get a new
FAQ out shortly.

Q: What do the error messages:
     Unable to read internal header at ...
     Unable to find CRLF at ...
     Unable to parse internal header at ...
     Unable to parse message date at ...
     Unable to parse message flags at ...
     Unable to parse message UID at ...
     Unable to parse message size at ...
     Last message (at ... ) runs past end of file ...
   mean?  I am using mbx format.
A: The mailbox is corrupted and needs to be repaired.
   You should make an effort to find out why the corruption happened.  Was
    there an obvious system problem (crash or disk failure)?  Did the user
    accidentally access the file via NFS?  Mailboxes don't get corrupted by
    themselves; something caused the problem.
   Some people have developed automated scripts, but if you're comfortable
    using emacs it's pretty easy to fix it manually.  DON'T USE vi OR ANY
    OTHER EDITOR UNLESS YOU ARE CERTAIN THAT EDITOR CAN HANDLE BINARY!!!
   After the word "at" in the error message is the byte position it got to
    when it got unhappy with the file, e.g. if you see:
     Unable to parse internal header at 43921: ne bombastic blurdybloop
    The problem occurs at the 43,931 byte in the file.  That's the point you
    need to fix.
  c-client is expecting an internal header at that byte number, looking
   something like:
     6-Jan-1998 17:42:24 -0800,1045;000000100001-00000001
   The format of this internal line is:
    dd-mmm-yyyy hh:mm:ss +zzzz,ssss;ffffffffFFFF-UUUUUUUU
  The only thing that is variable is the "ssss" field, it can be as many digits
   as needed.  All other fields (inluding the "dd") are fixed width.
  So, the easiest thing to do is to look forward in the file for the next
   internal header, and delete everything from the error point to that internal
   header.
  Here's what to do if you want to be smarter and do a little bit more work.
   Generally, you're in the middle of a message, and there's nothing wrong with
   that message.  The problem happened in the *previous* message.
  So, search back to the previous internal header.  Now, remember that "ssss"
   field?  That's the size of that message.  Mark where you are in the file,
   move the cursor to the line after the internal header, and skip that many
   bytes ("ssss") forward.  If you're at the point of the error in the file,
   then that message is corrupt.  If you're at a different point, then perhaps
   the previous message is corrupt and has a too long size count that "ate"
   into this message.
  Basically, what you need to do is make sure that all those size counts are
   right, and that moving "ssss" bytes from the line after the internal header
   will land you at another internal header.
  Usually, once you know what you're looking at, it's pretty easy to work out
   the corruption, and the best remedial action.  I generally don't use repair
   scripts because I prefer the flexibility of manual repair.  Repair scripts
   will make the problem go away but may not always do the smartest/best
   salvage of the user's data.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.