Ever since I've migraded from courier pop3 to dovecot pop3 I'm constantly getting complains from users that went over system quota for short while and then their pop3 client downloads all messages again. I never happened with courier pop3. I think that dovecot does not handle dovecot-uidlist file safely so it can withstand such situations. rsync and other similar programs always writes to a copy of the file like dovecot-uidlis.xcb453 and on success unlinks old file and renames new one. Dovecot should not assume that write operation on dovecot-uidlist will succeed. Yes, I know I can put metadata like dovecot-uidlist somewhere else, on another partition but that really splits mailbox into multiple locations making for example backups way harder to make, restore, share etc.
On 09/23/2015 03:53 PM, krzf83 at gmail.com wrote:> Ever since I've migraded from courier pop3 to dovecot pop3 I'm > constantly getting complains from users that went over system quota > for short while and then their pop3 client downloads all messages > again. I never happened with courier pop3. I think that dovecot does > not handle dovecot-uidlist file safely so it can withstand such > situations. > rsync and other similar programs always writes to a copy of the file > like dovecot-uidlis.xcb453 and on success unlinks old file and renames > new one. Dovecot should not assume that write operation on > dovecot-uidlist will succeed.Dovecot doesn't assume that either. I don't know what exactly the problem is here, maybe some small mistake or maybe something larger that can't be fixed, but I'm sure it's not because Dovecot assumes that writes are succeeding. I don't unfortunately have time to debug it myself. The main reason why I haven't bothered even trying to support this use case is that there's no way to handle this 100% correctly and safely for IMAP (although I suppose you could get away with it working nearly always, and for POP3 it could be made to work 100% correctly).