I just still log into www.hotmail.com lol it's simple and it works. I don't open anything that looks dodgy, and hardly ever open a FW email unless I'm certain it's safe to do so, I usually delete them.
I just still log into www.hotmail.com lol it's simple and it works. I don't open anything that looks dodgy, and hardly ever open a FW email unless I'm certain it's safe to do so, I usually delete them.
I see the last update for Eudora (a blast from the past!) was in 2006. Seems to have gone like Mulberry. There is quite a lot of info about Eudora's file structure but I can see why importing it to an open format would be tricky.
(\__/)
(='.'=)
(")_(")
Been helped or just 'Like' a post? Use the Thanks button!
My broadband speed - 750 Meganibbles/minute
Qualcomm (the developer) decided to completely cease that kind of activity, to concentrate on more core telecomms business, about then, which was a shame 'cos I'd be using Eudora absolutely ages. As I understand it, they handed the source code and marketing over to Mozilla, and the new-ish Thunderbird OSE is basically a Eudora-like front-end on what is essentially the TBird engine. I'm sure there's more to it than that, probably including import capability and the way it handles data organisation.
I don't really want to switch to a completely new client unless it does a decent job of handling imports, at least of mails and folders, though I'd manually redo the address book, filters, etc, if need-be. Importing the Eudora stuff into Thunderbird was a pretty dismal failure - some bits simply vanished, and others were incomplete. At the very least, I need to feel confident it hasn't "lost" email data, because I'd guess here close to about 15 years of archived data in there. Maybe TBird OSE would make a better job of it, and of do, that may be the answer. I'd rather go vanilla TBird than the OSE version, partly because of potential for loss of future development of the OSE version, and partly because it appears to, at best, lag behind.
But in the end, whatever works, and solves the problem, will do.
MUA's aren't the only application that use a files ystem type structure within a file wrapper. In terms of storage efficiency the mbox model is probably better than maildir, However maildir is probably more robust than mbox. But in principle having all mail messages in one file is no different to having lots of file in one directory. After all, a directory is in essence only a file that contains file pointers.
And there are different variants of mbox (which include additional indexing files that speed up access) so it becomes quite a sophisticated storage system.
What are your particular concerns with it?
(\__/)
(='.'=)
(")_(")
Been helped or just 'Like' a post? Use the Thanks button!
My broadband speed - 750 Meganibbles/minute
It's very different, if a directory node is damaged, the emails are still recoverable, since fsck will dump dereferenced objects into lost+found, if an mbox file is lost, all your emails are toast.
Additional and non-trivial application code, fracturing and complicating an already dreadful format, inter-application incompatibility. Sophisticated generally means liable to ruin your day, in this context it's practically guaranteed.
Slow, more complex to code, prone to eradicating all your emails if there's the slightest filesystem problem, doesn't scale, horribly inflexible, works poorly with existing system tools.
It is a question of compromise though, aqnd the defects you describe appear to be as much about shortcomings of a particular file system. Outlook (for example) has an inbox repair tool, so if the .pst file (which is the same concept as an mbox file) is damaged it can do a repair - similar in principle to fsck on an ext2/3/4 file system. Ext3 is a journalling file system anyway and so file damage is less likely to occur (same almost true for NTFS).
But mbox has stood the test of time, and the principle (one file acting as a container to hold a file system like structure) is used by other applications, such as winzip, word, truecrypt and others.
While there is a risk, (as with any storage system) the likelihood of that risk occurring is small.
Last edited by peterb; 05-11-2010 at 11:07 AM. Reason: Typos, clarity
(\__/)
(='.'=)
(")_(")
Been helped or just 'Like' a post? Use the Thanks button!
My broadband speed - 750 Meganibbles/minute
No, I'm talking about the shortcomings of mbox itself. Explaining typical file-system behaviour merely serves to reinforce it.
Which is useless, if the file is dereferenced.
Less likely, but not unlikely either, that's why ext* has a lost+found directory.
No it hasn't, it still exists, but it's proven itself to be a inferior at storing email in every respect.
Most still follow 1 document per file concept (bar winzip, but that's an archiving format, it's meant to do that). And that trend has been increasing lately as developers realise that jamming everything into one file might not have been the brightest idea. mbox crams all your emails into a convoluted structure, somewhat like a zip, only without the compression benefits, and all of the risks involved, and no on file-system copies.
How does this impact the ordinary citizen who's just wondering which email client to try as a replacement for Outlook Express?
peterb (05-11-2010)
(\__/)
(='.'=)
(")_(")
Been helped or just 'Like' a post? Use the Thanks button!
My broadband speed - 750 Meganibbles/minute
my Virtualisation Blog http://jfvi.co.uk Virtualisation Podcast http://vsoup.net
I've never had any trouble or lost anything with OE 6. Does that mean I'm just lucky?
No, it just means that, like the vast majority of e mail users find, the storage system is robust enough to be usable for daily use. (I have mbox like files that are several Gbytes in size that were originally created seven or 8 years ago - true - they are backed up, but that is part of a general backup regime, not because I am unduly concerned about the integrity of the mail file store)
(\__/)
(='.'=)
(")_(")
Been helped or just 'Like' a post? Use the Thanks button!
My broadband speed - 750 Meganibbles/minute
There are currently 1 users browsing this thread. (0 members and 1 guests)