Thunderbird Question

[J Jude]

That strategy has been around forever.  Mailboxes can be too big for
memory, so email client developers often assume the mailbox will be on
disk.  If you want to delete a record near the beginning of a large
file, it's going to take a long time to shuffle all of the other
records to the front, because you have to read a bit, rewind, write a
bit, etc.

One obvious solution is to use a database, which would make more
efficient use of the disk.  Unfortunately, great performance comes at
a cost.  First, you lose the "standard" mailbox format, making mailbox
files more difficult to manipulate with standard tools.  Second, the
files are no longer human readable.  This can be useful, especially if
your mailbox ever gets corrupted.

One of the ads Gmail is showing me right this minute is for "Advanced
Outlook Repair: Repair corrupt Outlook PST fiiles... $249.95!"   Wow.
Thank  you very much, but I would rather Thunderbird stick with human
readable files, and leave me with my safe, slow mailbox, and my $250.

Another way to get better performance is to use an index file.
Thunderbird, kmail, and other common mail programs use this strategy.
Even for a large mailbox, the index file is small, so it can all fit
into memory and be manipulated more readily.  To delete a message, you
mark it deleted (both in the mailbox file and in the index), instead
of shuffling all the messages around.  If the index file gets
corrupted, or is out of date, you can rebuild it fairly quickly.

I think Thunderbird is using the right strategy.  Keep my email safe.
Be conservative.  And maintain performance by not compacting the
mailbox file, when it slows down the user.

However, I do think that Thunderbird should have an option to
automatically and slowly compact the mailbox during times of no user
activity.

I think kmail had a similar usability issue with corrupted indices.
Just like Thunderbird wants the user to manually compact mailboxes,
kmail expected the user to manually deleted a corrupted index, instead
of automatically rebuilding.  I'm not sure if kmail ever fixed that
problem, because we stopped using it.  It's unfortunate, but users
don't have a lot of patience for stuff like this.




On Nov 10, 2007 2:50 PM, Borden Rhodes <dominussuus at gmail.com> wrote:
> Good autumn evening, fellow heroes,
>
> I posted a perceived bug to the Mozilla Thunderbird forums looking for
> opinion and I was unsurprised about the response I got.  The original
> posting is here http://forums.mozillazine.org/viewtopic.php?t=601991
> but for those wanting the 500-words-or-less summary here it is:
>
> I was migrating one of my clients from Thunderbird to Outlook using
> the roundabout process of converting mbox into emls then loading those
> emls into Outlook Express then importing the whole thing into Outlook.
>  When I decompressed the mboxes, they were about 4 times the size that
> Thunderbird said they should be.
>
> It turns out that Thunderbird does not remove e-mails (or their
> content) from their mbox database  after moving e-mails to trash and
> emptying it.  The only way, without a plug-in, the user can do this if
> s/he manually goes to each folder and orders it to Compact.
>
> I found this rather surprising and I got explanations ranging from
> 'having to rebuild the mbox each time will make it prohibitively slow'
> to 'even if TBird did remove the files they wouldn't be completely
> 'gone' - you can still reconstruct them with drive recovery software.'
>
> I felt like they were making excuses and after one of them said 'if
> you don't like it, take your money elsewhere' I took him up on his
> offer and switched to Claw Mail :D.  Is anyone else as surprised by
> Thunderbird's housekeeping as I am?  To see whether this behaviour was
> as common as the Thunderbird proponents claimed, I created and deleted
> some items in KMail - which also uses mboxes and one-big-files - and
> KMail didn't leave any residuals in their databases.
>
> --
> ubuntu-ca mailing list
> ubuntu-ca at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-ca
>