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

[Janne Peltonen]

And Centos 5.11, Linux 2.6.18-407.el5.


--Janne

On Fri, Apr 22, 2016 at 05:43:11PM +0300, Janne Peltonen via Info-cyrus wrote:
> 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
> ----
> 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