On Thu, 27 Dec 2001, Benjamin Smith wrote:
> > I was thinking of that too, but since mutt still knows how to mark the
> > messages to be deleted after the purge, why not delete them after the
> > check... ?
>
> Good question... Currently the code just does this (in
> mbox_sync_mailbox):
>
> /* Check to make sure that the file hasn't changed on disk */
> if ((i = mbox_check_mailbox (ctx, index_hint)) == M_NEW_MAIL || i == M_REOPEN
> {
> /* new mail arrived, or mailbox reopened */
> need_sort = i;
> rc = i;
> goto bail;
> }
Hmm... mutt's paradigm is to work gracefully even when there are different
processes accessing the same mailbox at the same time. Let's imagine what
would happen if person 1 and person 2 are both accessing the same mailbox,
and we made mutt continue to expunge the messages even after it detects a
change in the mailbox:
1. Person #1 presses $ and is asked whether to expunge messages.
2. Person #2 deletes a message.
3. Person #2 notices that he deleted the wrong message and wants
to undelete it.
4. Person #1 presses "y", causing all deleted messages to be
expunged, including the one that Person #2 wanted to undelete.
I'm guessing that's why the mutt authors coded $ to abort in case of a
mailbox modification; if they just made it blindly not abort, then mutt
would lose some "transaction safety".
I think a better way of handling this would be for mutt to remember what
messages were marked as deleted when "$" was pressed. If the user then
confirms the deletion but mutt detects a changed mailbox, it should go
read the mailbox again, then delete any messages that were originally
marked as deleted and are still marked as deleted.
I may not be fully aware of any problems in implementing this, though
(maybe my reasoning is flawed somewhere, maybe there's a technical reason
that makes it difficult to implement this, etc.).
