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