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

Janne Peltonen janne.peltonen at helsinki.fi
Fri Apr 22 11:21:45 EDT 2016


Hi!

Both. The message cannot be seen via IMAP in the destination mailbox and it
doesn't exist on the filesystem. 

But the message is clearly somewhere, probably in core: When I killed all the
other imapd processes that could've been accessing the same mailbox (that had
users who were mentioned in the acl of that mailbox), the messages I'd tried to
copy all both appeared on the file system (all at the same time, as confirmed
by calling "stat" on the message files - the Change timestamps were all the
same, and coincided with the time of the process kill) and could be fetched by
imap, too.

This is a replicating setup, if that makes any difference.

Right now, everything seems to be working, and I haven't seen this behaviour
earlier in the ~17 years I've been using Cyrus with shared folders in here - or
the 10 years I've been using replication - so I don't really know how to even
recreate the problem.

The semantics of the OK response *should* be "Message is safely written on disk
(so you can delete the original message)", shouldn't it?


--Janne

On Sat, Apr 23, 2016 at 12:56:15AM +1000, Bron Gondwana wrote:
> 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


More information about the Info-cyrus mailing list