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@xxxxxxxxxxx > > ---- > > 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 ---- 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
