Eudora 7 In box damaged.. how to repair?
ma...@bkwds.comcast.net
Today I had some corruption from doing a CHKDSK on the D:\ drive with
Eudora open and forcing a dismount. The In box was corrupted as the
STATUS symbols are all `?� (question marks.) Also a new IN message that
was replied to shows no `replied� status. I have a backup of the In box
file from 1-15-10 backup.
How to edit or repair?
-ed
Jim Higgins
You should have a more recent IN box backups in the form of
IN.MBX.001, IN.mbx.002, etc., with the lower numbered ones being the
more recent.
Possibly too late since these files get overwritten every time you
close Eudora, but... change the name of IN.mbx.001 and IN.toc.001 to
something If Eudora is open, DO NOT close it because this overwrites
these files with the current IN.mbx and IN.toc files.
Change their names immediately to something like IN003.mbx (and
corresponding IN003.toc), and do the same for the .002 and .001 files.
Note which is the newest. It should be the lowest numbered one.
Now you can close Eudora and restart it and you will see the new
mailboxes you just renamed. Look at the newly named mailboxes and
pick the one with the best set of recovered messages. Now from within
Eudora drag any more messages you want to recover/keep from any other
IN-boxes into this recovered mailbox. When you have the best possible
recovery, you can delete (or rename) all the other mailboxes and
rename that best one to IN.mbx.
Now if any messages are flagged as STATUS "?" you can highlight only
those messages. right click and "change status" to whatever you want.
I suggest you read them before doing this so you can decide whether to
mark them "read" or "unread".
NOTE: If you delete the .toc file corresponding to any .mbx file you
will lose the replied/sent/etc status of all messages in that mailbox
and all will appear to be "read." so keep those mbx and toc files
paired up as far as the filename before the .mbx and .toc extensions.
Lots of words above, but it all amounts to changing names of recently
backed up IN boxes while keeping the filename before the extension in
sync for each mbx/toc pair so you don't lose the status of the
messages in that mailbox. Once you do that they won't be overwritten
by new backups and you can review and recover at your leisure
All of this is perhaps a good reason to set the value for InOutBackups
in Eudora.ini to a value higher than 2 or 3. Click on the link below
to view your current setting and to change it if you wish.
<X-Eudora-Option:InOutBackups>
Good luck.
--
Please don't be a "Help Vampire"
http://slash7.com/pages/vampires
ma...@bkwds.comcast.net
<inv...@invalid.invalid> brought the following to our attention:
>On Thu, 21 Jan 2010 20:29:46 -0500, ma...@bkwds.comcast.net wrote:
>
>>
>>Today I had some corruption from doing a CHKDSK on the D:\ drive with
>>Eudora open and forcing a dismount. The In box was corrupted as the
>>STATUS symbols are all `?� (question marks.) Also a new IN message that
>>was replied to shows no `replied� status. I have a backup of the In box
>>file from 1-15-10 backup.
>>
>>How to edit or repair?
>>
>> -ed
Thanks.. was not aware of that feature. Have set the level to 3.
Using the backed up IN box and toc from 1-15-10 and copying/manipulating
/renaming the normal In box, was able to drag and manually change status
to get nearly a complete recovery of the replid-to IN emails. There may
be a few recent messages where the blue read/not read symbol is wrong,
but that's of no consequence really.
John H Meyers
> You should have a more recent IN box backups in the form of
> IN.MBX.001, IN.mbx.002, etc., with the lower numbered ones
> being the more recent.
>
> Possibly too late since these files get overwritten
> every time you close Eudora...
Each of the file sets (one for "In" and another for "Out")
is "aged" only when the corresponding mailbox is _compacted_
If the number of "generations" is 2 (the default),
then each "compact" operation on a given mailbox does this:
xxx.002 -> discarded
xxx.001 -> becomes xxx.002 (not compacted)
xxx -> becomes xxx.001 (not compacted)
A newly rewritten (compacted) file then becomes "xxx"
If a mailbox is not compacted for several months,
then there will be no "aging" for all that elapsed time.
If you deliberately perform "compact" on an individual mailbox,
(or all mailboxes) then "aging" occurs immediately.
If there are 2 generations (the default)
and you perform "compact" three times in succession,
then all of xxx, xxx.001 and xxx.002 will be identical files
(assuming no corruption during these operations).
By default, automatic compacting occurs when 50% of an MBX file
consists of "deleted" (or rewritten, or transferred) messages
at the time when the mailbox is closed.
If we open Trash and then empty Trash, for example,
it is then 100% "deleted" messages, so it compacts (to an empty file)
the moment we close it after we have emptied it.
If you simply accumulate incoming mail without deleting or transferring elsewhere,
and similarly accumulate outgoing mail without repeated saving (rewriting)
during composing, and never initiate "compact" or "compact all,"
then you may hardly ever be "aging" the potential backups of "In" and "Out"
The automatic saving of these "generations" for "In" and "Out"
was apparently a defense against the fact that many users
never create another mailbox and never "archive" old mail.
The indefinite accumulation of old mail, plus the fact that
these particular TOC's are always memory-resident,
and that there is commonly a lot of "turnover" of the content
(many messages become deleted or rewritten), causing more frequent
compacting, exposes these two mailboxes to greater risk of corruption,
so these "Eudora air bags" were installed to possibly cushion crashes :)
--
ma...@bkwds.comcast.net
<jhme...@nomail.invalid> brought the following to our attention:
>On Thu, 21 Jan 2010 21:01:18 -0600:
>
>> You should have a more recent IN box backups in the form of
>> IN.MBX.001, IN.mbx.002, etc., with the lower numbered ones
>> being the more recent.
>>
>> Possibly too late since these files get overwritten
>> every time you close Eudora...
>
>Each of the file sets (one for "In" and another for "Out")
>is "aged" only when the corresponding mailbox is _compacted_
>
>If the number of "generations" is 2 (the default),
>then each "compact" operation on a given mailbox does this:
>
>xxx.002 -> discarded
>xxx.001 -> becomes xxx.002 (not compacted)
>xxx -> becomes xxx.001 (not compacted)
>A newly rewritten (compacted) file then becomes "xxx"
>
>If a mailbox is not compacted for several months,
>then there will be no "aging" for all that elapsed time.
Interesting! Being a neat-freak, I routinely press the Compact All tool
button thinking it's saving space. The In Box is ok this morning but
I've found a `newsletter� mailbox with the column widths all messed
up and a title bar say it's in the /~temp folder, with all ? marks along
the right edge. Started to copy & rename the mailbox but it seemed
to straighten itself out ok. I simply change all status to READ and re-
spaced the column widths. No need to restore from backup RARs.
The problem started yesterday morning when I did a Win SEARCH
for .bmp files and tried to `select all� and compact from inside the
search results. This ended up freezing the PC so bad that AC power
had to be cycled at the UPS (battery backup) box!! Then I recall
running a /chkdsk frantically on the d:/ drive which warned of open
or mounted files.
I was PO'd due to the lockup and wasn't being rational as usual.
OTOH it may have been from cutting the power with Eudora open.
-ed
John H Meyers
> Note that you get a backup of the IN box (and OUT box)
> every time you close Eudora...
I have just opened and closed Eudora FIVE TIMES,
and the "Date Modified" of all my ".001" and ".002" files
remains as of two days ago.
For the record, each mailbox set is "aged"
only when the "In" or "Out" mailbox is _compacted_,
either by manual request
or automatically, by it having more than 50% "unusued space"
at any time that the mailbox is closed
(the "percent" threshold can be varied by an internal setting)
> so you can burn thru a setting of three backups pretty fast.
And you can also go for months without ever an automatic backup
of either "In" or "Out" (and no other mailboxes get such backups at all),
as some of my local clients unhappily find, after it's too late.
It all depends on your actions, and how you use your mailboxes,
and what happens within your computer, and Windows, etc.,
which is what the many previous examples were designed to illustrate.
The ".001" etc. files for "In" and "Out" save those original mailboxes
(and only those) just before any time they are compacted,
which enables you to go back to "before compacting"
if (and only if) you notice "after compacting" damage
soon enough that you haven't "aged out" your last undamaged versions,
as was correctly noted above.
Damage at any other time, or from any other cause,
not associated with compacting, or to any other mailboxes,
may not leave you with any recent recoverable versions,
so maintaining a normal backup system remains prudent.
--
Don Williams
<ma...@bkwds.comcast.net> wrote in message
news:qkvhl597qe4b5qaf3...@4ax.com...
The only solution I found was to look at each message and use the "change
status" function. Takes time but it works.
DAW