> I'm not sure about "compacting" the mailboxes.
> I delete trash on a daily basis. I empty the trash weekly or monthly.
> Are you suggesting to "compact" the IN box everytime I delete some emails?
Compacting occurs automatically, IIRC when 50% of the file space is unused.
During compacting, not only is the mailbox (message file) rewritten,
but also its "table of contents" (TOC), from which is displayed
the "mailbox window."
"Deleting" messages consists of removing their TOC entries,
so that deleted messages are no longer listed,
but the message remains in the mailbox file,
much as "deleted" computer files remain stored on disk,
while only their "directory" entries are removed.
It would appear that what went wrong in your case was that
the TOC was found to be either missing, corrupt, or out of date
(not as recently updated as the mailbox itself),
hence was rebuilt to re-index everything still in the mailbox file,
which would include anything deleted, moved, or updated
since the last compacting.
The TOCs of built-in mailboxes (e.g. In/Out/Trash) are held in
RAM memory all the time, which exposes them to increased chance
of getting damaged, particularly if one does not trim down these mailboxes
to contain only a modest amount of mail, by moving old mail instead,
to user-created mailboxes.
One has a choice to either use separate files for mailbox TOCs,
or to use Mac "Resource forks" to store them. It seems possible
that using resource forks, which is now the default,
might be less robust a method than the original "separate TOC files" method.
> And how does one "Compact" a mailbox?
You do not have to do it yourself, since eventually it will be done for you,
although you may always elect to do it, whenever you want,
either by clicking any individual mailbox size display,
or with the Option key to compact all mailboxes
(see page 312 of version 6.2.4 user manual)
Manual compacting does not help prevent TOC corruption,
although it may result in fewer "resurrected" deleted messages
if and when any TOC may ever need to be rebuilt, plus smaller backups
(if you or Time Machine make backups).
Keeping the size of built-in mailboxes small is what will help prevent
the need to rebuild damaged TOCs, as well as possibly changing back
to the original "separate TOC file" method.
--
Rush - 09 Jun 2009 19:02 GMT
> > I'm not sure about "compacting" the mailboxes.
> > I delete trash on a daily basis. I empty the trash weekly or monthly.
[quoted text clipped - 18 lines]
> which would include anything deleted, moved, or updated
> since the last compacting.
John:
Thank you very much. I've used Eudora since the Mac 512 days and I
didn't know what you just explained. Would you recommend using the
"old-style ".toc" setting? Will it apply to all mesages or just those
received after changing the setting? Are there drawbacks to using the
".toc" setting?
Ralph
> The TOCs of built-in mailboxes (e.g. In/Out/Trash) are held in
> RAM memory all the time, which exposes them to increased chance
[quoted text clipped - 23 lines]
> the need to rebuild damaged TOCs, as well as possibly changing back
> to the original "separate TOC file" method.
John H Meyers - 09 Jun 2009 21:39 GMT
> Would you recommend using the "old-style ".toc" setting?
The reports I have seen suggest that "old style"
(separate files, rather than resource forks) is more reliable.
Of course, no opinion is unanimous, and "YMMV"
> Will it apply to all messages or just those received after changing the setting?
I believe that any particular mailbox will change from one mode to the other
when next compacted (or at least as soon as that).
> Are there drawbacks to using the "old style .toc" setting?
I think the drawbacks are all with the "new style" (resource forks).
Hasn't Apple been "deprecating" the continued use of resource forks anyway,
hoping to eliminate them entirely? http://trac.cyberduck.ch/ticket/374
Or almost entirely? http://svn.haxx.se/dev/archive-2006-09/0693.shtml
http://macosx.com/forums/mac-os-x-system-mac-software/271333-question-jpg-attach
ments.html
For some while, I believe that "Rsync"
didn't even originally handle resource forks at all:
http://www.whoopis.com/howtos/rsync-hfs-howto/
One of the safety mechanisms that Eudora uses to ensure mailbox integrity
is to compare the last "modification time" of each mailbox file
to its corresponding resource fork. Do resource forks, however,
have their own independent "modification time"?
http://en.wikipedia.org/wiki/Resource_fork
Of course, all of one's Eudora settings are also in a resource fork, FWIW :)
--
Rush - 10 Jun 2009 00:09 GMT
John:
I read your post with interest. Once again I realize how little I
know about the inner workings of the Mac. I found the article by Bates
to be intriguing although my eyes glazed over on some of the technical
descriptions. A few decades ago when I learned basic programing, I felt
that I knew all I needed to use a computer. Since my first computer was
a Mac128k, I seldon had a chance to use that programming knowledge,
except when using a Mac basic programing application. How far we've
come.
At least I'll have an insight if the same problem comes up again.
Again, I want to thank you for the time you took to answer my
questions.
Sincerely
Ralph
Hauke Fath - 10 Jun 2009 13:12 GMT
> > Would you recommend using the "old-style ".toc" setting?
>
> The reports I have seen suggest that "old style"
> (separate files, rather than resource forks) is more reliable.
On my Quadra 840, at least, switching to old-style .toc files was quite
a spectacular speed-up, too.
> Of course, no opinion is unanimous, and "YMMV"
What he said.
hauke

Signature
Now without signature.
Julian Y. Koh - 24 Jun 2009 17:35 GMT
> > Are there drawbacks to using the "old style .toc" setting?
>
> I think the drawbacks are all with the "new style" (resource forks).
There is one drawback to using the old style .toc files - you lose 4
characters in the available mailbox name size. :)