IOERRORs accessing renamed mailboxes

[Bron Gondwana]

About the only thing we still get emailed by our
monitorcyrus process now is issues with mailboxes
being accessed directly after they've been renamed.
This is often through a client with multiple open
connections, but here's one from just a few minutes
ago:

(logging lines caused variously by the fastrename
patch and the auditlog patch - without them we
wouldn't have the timing information - username
and folder name redacted for privacy)

Apr 16 08:19:03 imap2 slot211/imap[18079]: RenameCopy: user.username.Subfolder -> DELETED.user.username.Subfolder.4805EEB7
Apr 16 08:19:59 imap2 slot211/imap[18079]: Deleted mailbox user.username.Subfolder
Apr 16 08:19:59 imap2 slot211/imap[18079]: auditlog: rename sessionid=<slot211-18079-1208343181-1> oldmailbox=<user.username.Subfolder> olduniqueid=<7ef27f3845a5fc37> mailbox=<DELETED.user.username.Subfolder.4805EEB7> uniqueid=<7ef27f3845a5fc37>
Apr 16 08:19:59 imap2 slot211/lmtp[9066]: IOERROR: stating header for user.username.Subfolder: No such file or directory
Apr 16 08:19:59 imap2 slot211/lmtp[11145]: IOERROR: stating header for user.username.Subfolder: No such file or directory

Notice that the rename-copy took 56 seconds (one
of the reasons we want fast rename!)

Also notice that two lmtp processes were both
waiting on a lock for at least part of that time
but didn't find the file once the lock went away.


I'm not too concerned about these, but I don't
like having IOERROR in my log file when it's
not a real error, because it makes parsing for
errors harder!

I may indeed track this down further in future,
but I thought I'd throw it out to the list just
incase someone else wants to fix it!

Bron.