Lex,

Good point.  I agree that the right thing is to (significantly) speed up the Celeste database functionality, probably making it more incremental.  (And hopefully adding some more functionality, but that is another message.)

The intent of my changes was as a stop-gap solution.

I find the present setup is too slow for doing auto-saving during a session.  A bad example is when I fetch the new Squeak group messages, Celeste takes (at least) 75 seconds to save the database before deleting the messages from the server (and this is on my pretty fast machine).  In that time, the POP3 connection times out, and so the delete from server can not happen.

I hate to loose email, so I do support a strong safety-net.  But when I realized that it was already saving the message contents securely, and that this was only an issue of the index file being updated to reflect the new messages, I was less concerned.

It does however mean you have to be more aware of using compact to recover messages which have been lost.  I have made a further simple change to MailDB dbStatus which checks that the mail files were written in the saveDB write order (first messages, then index, then categories).  This should detect when the messages file has been updated but the index and categories were not subsequently written, and then prompt for compact.

I will shift things around a bit so that the auto-save changes are an independent decision from the updateTOC and other changes I have made.

Mike