Re: Minor patches for builds against ancient platforms

Quoting Joseph Tam : > If this is output on the dovecot server itself so there's no mismatch > in pathnames. Have you checked whether the dovecot user can traverse > all the way from / to /u2/usermail/luser/ The dovecot user, as in the "dummy" user dovecot uses for

Re: Minor patches for builds against ancient platforms

I've tried changing how I symbolically linked the mailboxes, i.e., creating a sub-directory that is symlinked into the user's mail/ directory versus symbolically linking the mbox files themselves, etc. No dice. Permissions are fine. I've even resorted to changing the index locking strategy,

Re: Minor patches for builds against ancient platforms

I've gone through and recompiled sendmail (enabling HASFLOCK) and procmail (disabling lockf()) to harmonise the locking strategies, as it seems various authors of email software over the years have pontificated with great force and wind about which locking strategy was truly FUBARed and which was

Re: Minor patches for builds against ancient platforms

Timo Sirainen inscribed: Have you set mbox_very_dirty_syncs=yes? That should be helpful. Oh, that sounded like a risky option. I do have mbox_dirty_syncs enabled. Are there still "safety checks" with the extra down-and-dirty sync option? Joseph Tam-a-lyne wrote: > doveadm user $user > >

Re: Minor patches for builds against ancient platforms

On 12 Jun 2017, at 2.09, M. Balridge wrote: > >> 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.

Re: Minor patches for builds against ancient platforms

On that note, has anyone written a tool that "harmonises" users mail directories' permissions - ideally reading the dovecot configuration to assess where *THE* mail directories are actually used by dovecot? doveadm user $user which will supply the second half: it will spit out the

Re: Minor patches for builds against ancient platforms

David "Show Me The Vintage!" McGuire wrote: > I for one am finding this thread extremely entertaining. I have to > wonder how you'd sound if you came across a machine that was actually > OLD. ;) Well, I am fond of "old" hardware, which may still be on the wrong side of the New/Old divide for

Re: Minor patches for builds against ancient platforms

I do know that this little box of horrors has 200-300MB mbox INBOXes on an ext3 filesystem formatted in 2005. I am very nervous about converting them to Maildir at this point. Fortunately, it just involves reformatting the data and a little reconmfiguration of dovcot. If you can find the

Re: Minor patches for builds against ancient platforms

On 06/09/2017 05:13 PM, M. Balridge wrote: > I do know that this little box of horrors has 200-300MB mbox INBOXes on an > ext3 filesystem formatted in 2005. I am very nervous about converting them to > Maildir at this point. If I could get someone (or something) to the site and > replace it with

Re: Minor patches for builds against ancient platforms

> >> Warning: Transaction log file > /home/luser/mail/.imap/INBOX/dovecot.index.log > >> was locked for 95 seconds (rotating while syncing) > > Timo recently explained to me it's probably caused by slow I/O or > processing. This explanation is consistent with my observation that > the users who

Re: Minor patches for builds against ancient platforms

On 9 Jun 2017, at 5.03, M. Balridge 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

Re: Minor patches for builds against ancient platforms

"M. Balridge" writes: 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 resemble that remark. Warning: Transaction log file /home/luser/mail/.imap/INBOX/dovecot.index.log

Minor patches for builds against ancient platforms

I was recently asked to upgrade some neolithic aged software (UW-IMAP, sendmail 8.12.x, apache 1.3, amongst other horrors). The box is physically remote, so an aggressive "new flush" wasn't an option. I've been able to upgrade the compiler to gcc-3.4, openssl to 1.0.2k, glibc, php to something