Shared folder, COPY, OK, message nowhere to be seen

[Janne Peltonen]

Hi!

Oh. Sorry. I thought I'd forgot something important, must be the fact it's
Friday night.

2.4.17 from Simon Matter's srpm. Revision 6 of said rpm.


--Janne

On Fri, Apr 22, 2016 at 11:27:40PM +1000, Bron Gondwana via Info-cyrus wrote:
> Version?
> 
> On Fri, Apr 22, 2016, at 21:47, Janne Peltonen via Info-cyrus wrote:
> > Hi!
> > 
> > I've always thought that IMAP COPY should only say OK once the message file is
> > safely on the disk. So that it should block, should another imapd process be
> > holding a write lock to the folder.
> > 
> > Now today I experienced something very weird. There was a shared folder. If I
> > tried to copy a message to it (speaking raw imap), I immediately got an OK. And
> > the folder metadata reflected the change. However, the message wasn't on the
> > disk. And wasn't retrievable using IMAP.
> > 
> > I tried this multiple times. Frustrated, I ended up killing the active imapd
> > processes of all other users that had ACL rights to the folder. My messages
> > immediately appeared on disk and were retrievable by IMAP. As if they'd been
> > in-core of my imapd process and waiting for a chance to be flushed to disk.
> > Even if the imapd process had returned OK, which I'd thought would've meant
> > they'd already been written to disk.
> > 
> > Now, apparently, one of the users had copied mission critical messages to said
> > folder and they had disappeared. Disappeared from the original folder and not
> > shown up in the destination folder. Which was the reason I started
> > investigating this.
> > 
> > Now, after having killed the imapd processes, I seem to have permanently
> > deleted all the messages that might have been in-core of any of those processes
> > (that had told their clients that the messages would've been on disk, i.e.
> > COPY -> OK). I killed the imapd processes while thinking that 1) there could in
> > no way be the slightest possibility that the messages hadn't been flushed to
> > disk from the core of the imapd processes after COPY, as the imapd had answered
> > OK to the client's COPY command, SO 2) one of the other users' clients must
> > have had a rule that immediately moves the messages away. But apparently, this
> > wasn't the case.
> > 
> > Has anyone else encountered something like this?
> > 
> > 
> > --Janne Peltonen
> > ----
> > Cyrus Home Page: http://www.cyrusimap.org/
> > List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
> > To Unsubscribe:
> > https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
> 
> 
> -- 
>   Bron Gondwana
>   brong at fastmail.fm
> ----
> Cyrus Home Page: http://www.cyrusimap.org/
> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
> To Unsubscribe:
> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus