Re: [bug-mailutils] mailbox corrupted

[Alain Magloire]

Bonjour,

  Apology, I did not follow the entire thread. 

> 
> Yes, this can be it. Imap4d was not able to cope with such third-party
> modifications to the mailbox that decrease its size (by removing or
> editing some messages). I have installed the attached patch. It
> should apply cleanly to version 0.6. After applying the patch, imap4d
> will issue untagged response whenever the mailbox is shrunk by another
> program. If the client is able to handle it, it will update its data.
> If not, it will close the mailbox (mutt appears to prefer this way).
> In any case, mailbox will not be corrupted.
> 
> There are two issues, though:
> 
> 1. If a client updates any messages (by updating their flags or
> contents) and these changes are not flushed before the mailbox
> is shrunk by another program, such changes will be lost.
> This is a reasonable price for preserving mailbox contents.
> 

It is an interesting point, I think we choose this approach for
performance reasons, meaning that the flags will only be flush to the
disk on an EXPUNGE call, when doing CLOSE or reselecting another mailbox.
It was counter productive to flush on every STORE.
So if n clients access the same mbox our problem is to detect the state change,
propagate the notification back and reset our state.
I though we could handle this.

> 2. If the third-party program edits the mailbox in a way that increases
> its size (say, by appending an extra header to any message), imap4d
> is not able to tell such changes from appending a new message and the
> mailbox corruption can still occur. This case is being worked upon.
> 

Yes, IIRC, it was the premise of imap4d_sync()(sync.c) code, to handle
appending messages, this code was suppose to issue notification tags for new 
emails ...

> Anyways, modifying the mailbox, except appending new messages
> to it, while it is being worked upon by another program is not a good
> idea...
> 

In that case ... I still like the machette idea ...

        > +/* Alain: How to handle a shrink ? meaning, the &address@hidden@^& 
user start two
        >     browsers and deleted emails in one session.  My views is that we 
should
        >     scream bloody murder and hunt them with a machette. But for now 
just pla=
        > y
        >     dumb, but maybe the best approach is to pack our things and leave
        > -   .i.e exit()/abort().  */
        > +   .i.e exit()/abort(). =
        > 
        > +
        > +   Sergey: Nope, we shouldn't abort. Handling it with 
MU_EVT_MAILBOX_CORRUP=
        > T
        > +   is sensible enough. The caller must decide what's the best 
approach
        > +   in this case. The simplest one is reopening the mailbox. Imap4d 
currentl=
        > y
        > +   does that. */

But I think you are right .. we can do a better job at this.
Probably the implementation of mailbox_is_updated() for MBOX, should be more 
reliable in
the way it detects corruption and yes definitely agree we shoul notify the 
observers.

Is the IMAP RFCs clear on the issue of multiple access and the way to handle
shrinking mailboxes...


> Let me know if you experience any problems with the patch.
> 

Cool !!