On Sun, 18 Feb 2007, Per Foreby wrote:
Does mailutil use locking like imapd and dmail/tmail, or could I cause problems if I just run "mailutil prune"?
mailutil uses the same c-client library as imapd, [dt]mail, Alpine, etc.; so it follows all the same locking strategies as these other programs.
If mailutil obeys locks, what happens when it encounters a locked folder? Can I run into a deadlock or do I just get an error message?
The precise locking strategy depends upon the mailbox format; but in general a mailbox has two locking states: shared and exclusive. Exclusive locks are held for very brief periods of time, when the locking process is in the physical act of rewriting mailbox data.
With traditional UNIX mailbox format (and a more obscure one called MMDF), there is only limited sharing. One process can have the mailbox open, while this is going on another process can append to the mailbox. However, multiple processes can not have the mailbox open or append simultaneously. Multiple processes seeking to append (mail delivery) must wait their turn.
For open in traditional UNIX mailbox format, there is a mechanism called "kiss of death" in which the new process sends a "commit suicide" signal to the current process. If the current process kills itself, then the new process seizes the open lock for itself. imapd responds immediately to a kiss of death. ipop3d ignores a KOD if there was activity on the POP3 session in the past 3 minutes.
With all other formats, shared open is permitted; and in mbx and mix formats shared expunge is also permitted. Users don't see the impact of any locking; shared access just works. However, disk space occupied by expunged messages is not reclaimed until such time as a checkpoint operation occurs in an single-access session. In other words, space reclaimation requires exclusive access, but it doesn't block for it. Instead, it just relaims the next time it has a chance.
I would not recommend doing an auto-prune (as you envision) with traditional UNIX mailbox format because of kiss-of-death; an auto-prune would suddenly kill a user's active session.
Your suggested auto-prune should work fine with other formats. With other formats, if a session is open on the mailbox, the autoprune will successfully delete and expunge the messages; but the space won't get reclaimed because there is another session. However, the other session will notice the deletes and expunges. After the autoprune exits, the other session will reclaim the space at its next checkpoint (assuming that it is the only other session...otherwise the reclaim is deferred until there is only one session at checkpoint time).
Of course, the autoprune will always be OK if there is no other session open on the mailbox, no matter what format.
-- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ Imap-uw mailing list [email protected] https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
