Oh, one more reply:
On Wed, 2008-08-20 at 14:32 -0700, Jonathan Herbach wrote:
if (mbox->mbox_lock_type == F_RDLCK) { /* FIXME: we shouldn't fail here. it's just a locking issue that should be possible to fix.. */ mail_storage_set_error(storage, MAIL_ERROR_NOTPOSSIBLE, "Can't copy mails inside same mailbox"); return -1; }
So I'm currently using: mbox_write_locks: fcntl When I was using version 9 the relevant config setting was: "mbox_locks = fcntl", which plus the config suggestion "fcntl: Use this if possible" led me down this path.
Does anybody know why this code was designed this way / why it is different from 0.99 behavior / etc?
The mbox code (and a lot of other code) was rewritten since v0.99. The problem here is simply that the mbox is read-locked first for reading the message, but only after that it figures out that it should actually be write-locked since the destination mailbox is also the same. So the possibilities to fix this are:
a) Unlock the mailbox, write-lock the mailbox and look up the message offset again in case the mbox was modified while the mbox was unlocked.
b) Somehow figure out earlier that the mbox needs to be write-locked and do it instead of read-locking.