I’ve used Eudora for around 25 years as my email client and in the early days, when the inbox got too big, I had it crash every now and then, necessitating the program to rebuild the table of contents. From memory I’ve lost some emails back then, too, and had to ask friends to re-send. But, by and large, it’s been largely stable, and since Windows 7 I don’t recall it crashing so badly that I would be up shit creek. Till last night.
Normally, Eudora has back-ups for its in- and outboxes (which it renames with 001 and 002 suffixes) so in the case of a lost ’box, you can rename the old ones and hopefully not lose too much. But what if a crash was so severe it would take out not only the in- and outboxes, but also the content of the back-ups, as well as your third-quarter email folder? That’s exactly what happened.
I haven’t gone back into Windows to find out what caused the series of crashes but it seems to have begun with RuntimeBroker.exe and ntdll.dll. I’m not even going to pretend I know what all this means:
So what do you do when you’re up shit creek and renaming mailboxes (which I’ve had to do when we had a fuse blow) doesn’t work?
The most recent back-up I had was from September 5, and a lot happens in email-land for me over the course of six days. But it was the most recent, and it had to be the starting-point. So, first up, I retrieved them from Windows Backup and put them into a temporary folder (you can’t put them into the original folder).
The third-quarter ’box’s contents were still there, but the table of contents had been corrupted, but it had six days’ worth of changes to it. I renamed this to Q3 In (2), closed Eudora, and placed the backed-up third-quarter mailbox and table into the Eudora folder.
Then it’s the laborious process of seeing how they differ. The best thing to do—and why Eudora remains superior to so many later programs—is to line up the mailbox windows side by side, size them the same, sort them both by date, and begin going through screen by screen. If the first email and the last email are identical, chances are the ones in the middle are identical, so you’re only looking for the emails in the corrupted table that are newer. You then have to shift them one by one into the backed up one. I deleted the identical ones from the corrupted mailbox and by the end of the exercise I had over 4,200 emails in the trash.
The status (read, replied) is gone after the transfers but it’s a tiny price to pay for completeness.
Then the inbox. Same story: there was a 001 ’box that had survived the crash but none of the tables of contents were usable.
In this case, it’s fortunate we use Zoho as our email service. I went into the trash folder, where all checked emails wind up after POP3 access, and transferred everything from the 5th to the present day into the inbox. Fortunately, from there it’s not difficult to do a fresh POP3 access. Again, I closed Eudora, put the backed-up inbox into the main Eudora folder, and simply checked my emails. You do lose once more the status of the emails—you won’t know if you’ve replied to them—but at least you have an inbound record.
The outbox was a very sad case, and unfortunately the news is not good. Here, the table of contents was complete but the mailboxes (all of them) were blank. Therefore, clicking on the table of contents’ entries actually deleted them because the mailbox was corrupted. Strangely, all showed the correct sizes.
There’s no easy way here. You can’t take sent emails from Zoho and put them into your inbox expecting Eudora to be able to download them. The only solution I found was to forward each one, one by one, to myself from within Zoho. Then I placed them into either my third-quarter outbox or the active outbox. My own name appears in the recipient column, and the dates are wrong, but, again, if completeness is the aim, then it’s a small price to pay. Sadly, of the three recovered ’boxes and tables of contents, it’s the least elegant.
I imagine I could edit each email as a text file within the outbox and allow the table of contents to generate new entries, then recompile them into a new table, but after you’ve spent hours doing the first two ’boxes, you’re not keen on such a technical solution after 3 a.m. And there’s also no guarantee that the table would generate properly anyway.
Windows was the culprit here, as Eudora has always been very stable, and crashes like this are exceedingly rare, if you keep your in- and outboxes to reasonable sizes. I’ve never seen the back-ups get wiped out as well. A good case study in favour of regular back-ups, and maybe I might need even more frequent ones.
One thought on “Recovering mailboxes and tables of contents in Eudora after an extraordinarily massive crash”