On 9 Jun 2017, at 5.03, M. Balridge dovecot@r.paypc.com wrote:
- In src/lib/compat.h there is a definition for p(read|write) that conflicts with the one in /usr/include/unistd.h
On this box, there is a macro appended to the definition (to control whether or not THROW is defined in C++ "mode"). This is regulated by using the macro __THROW. I assume this is anachronistic.
I don't know about this. Anyway, can't apply this patch since it likely fails elsewhere.
- There was an odd overflow bug in the quota module. (Yes, would you believe that user quotas are used + enforced on this Frankenbox?) I assume it's a rarely seen issue because few Dovecot users compile the software in caves on computers powered by horse-pulled generator wheels. I suspect Timo's seen more Abominable Snowcreatures in Espoo than systems like these.
Simply adding an explicit 64 bit (unsigned) type to the constant multipliers seemed to address this. Of these two patches, this is probably the most "safe" and thus likely to be accepted into the main branch of code.
Yeah, I'll add that one. Not really sure if that's a generic 32bit problem. Nobody has previously complained about it though.
Thanks for the great software, as always, Timo. It's a testimony to your design and implementation acumen that software you've written in 2017 still runs on machines that went obsolete in 480 B.C.E.
For a long time Dovecot supported C89 compilers, but nowadays we at least require proper C99 compilers..
I am trying to track down one possible issue that could be locking-related, which causes some mailbox open operations to see to take longer than they should. Log entries like:
Warning: Transaction log file /home/luser/mail/.imap/INBOX/dovecot.index.log was locked for 95 seconds (rotating while syncing)
Warning: Transaction log file /home/luser/mail/.imap/INBOX/dovecot.index.log was locked for 92 seconds (rotating while syncing)
As Joseph mentioned, this is likely happening because Dovecot is doing a lot of work while keeping the log file locked. The "rotating while syncing" is probably not the real reason. I think it's just doing a lot of work on the mbox file itself (reading/writing/rewriting). Would be nice of course if it logged more information, but mbox format is a bit too legacy to spend much time on improving.
imap(luser): Error: fchown(/home/luser/mail/.subscriptions.lock, group=501(coregroup)) failed: Operation not permitted (egid=200(users), group based on /home/luser/mail - see http://wiki2.dovecot.org/Errors/ChgrpNoPerm)
imap(luser): Error: file_dotlock_open() failed with subscription file /home/luser/mail/.subscriptions: Operation not permitted
.subscriptions doesn't exist either as a file or a directory in the named directories.
Client is trying to subscribe, and Dovecot wants to create subscriptions file. Dovecot wants to preserve the group permissions from the /home/luser/mail directory, but it has no permission to set the file's group to "users", so it aborts. You could chmod 0700 /home/luser/mail if possible.
Is there a "filter" against dot-files being opened within the bowels of dovecot?
The problem above isn't dotlock, but rather the file permission preservation in general.