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 > > > br...@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 br...@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
