Minor patches for builds against ancient platforms

[Timo Sirainen]

On 9 Jun 2017, at 5.03, M. Balridge <dovecot at r.paypc.com> wrote:
> 1) 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.

> 2) 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.