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.h...@gmail.com>
