Re: [Dovecot] Dovecot & (Al)pine - resaving messages to Inbox
I suppose the OP does not sort by date but Arrival time (this means arrival time in the mailbox).
Exactly. I sort by arrival time, which in practice is the "unsorted" ordering based upon the mbox file itself. (Except I'd like to control the arbitrary "unsorted" order that I want by "resave to inbox" to handle reordering.)
Nicolas wrote:
- a quick grep shows this is 'normal' behaviour, as written in src/lib-storage/index/mbox/mbox-save.c
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?
Jonathan
Get thousands of games on your PC, your mobile phone, and the web with Windows®. http://clk.atdmt.com/MRT/go/108588800/direct/01/
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.
participants (2)
-
Jonathan Herbach
-
Timo Sirainen