Scott Galambos writes:
> Hello, I'm attempting to move form qpopper 4.1 to Dovecot 2.2.5 on
> Linux. When a user checks POP mail qpopper seems to make a
> .username.pop temporary file in the same /var/mail directory as the mbox
> INBOX file. Watching what dovecot does I don't see this happening.
Probably too quick (or perhaps you haven't configured dotlocking).
Qpopper locks the INBOX when it creates a drop copy: this can be a time
consuming operation, during which you can see the .$user.pop lock file.
Dovecot is more intelligent: it doesn't create copies, and goes out of
its way to avoid grautitous I/O. Most of the operations can be done by
consulting the indices.
However, I did contrive a situation to observe lock files being created.
1) Create large INBOX file test user (assuming mbox /inbox/testuser)
2a) In one window, run a shell loop monitor
while : ; do
ls -al /inbox/testuser.lock
done
2b) In another window, create a POP3 session and do an
operation that would require a lock:
telnet pop-server 110
USER testuser
PASS testpassword
DELE 1
... this still won't need locking -- not until ...
QUIT
If you use maildir format, it may still be too quick to catch. in this
situation, you can process trace the pop3 worker process to verify a
lock file is created.
> Is this .pop file a lock file or just a temporary file?
Temporary. If you have them lying around, qpopper crashed. Note:
dovecot makes lockfiles of the form "$user.lock".
> If its a temp file does dovecot do the same thing elsewhere? I'm
> concerned dovecot is not locking properly and there will be mailbox
> corruption, so I'm trying to get dovecot to mimic what qpopper does as
> much as possible.
By "mimic" you mean that locking works, but otherwise, you don't
want
dovecot to mimic qpopper: the former is much better. I have not had
problems with users complaining about scrambled files. As I said, process
trace your pop3 worker process if you need to verify the locking process.
Joseph Tam <jtam.home at gmail.com>