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
