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

[Bron Gondwana]

When you say the messages can't be seen... Do you mean they aren't on the file system, or that they aren't showing up via IMAP, or... ?

On Sat, Apr 23, 2016, at 00:48, Janne Peltonen wrote:
> 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


-- 
  Bron Gondwana
  brong at fastmail.fm