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 some of you: DECSYSTEM-20s and VAX 11/780s were the first "big" systems I ran across that I admired a great deal as an assembly language programmer and software engineer in general.
[ IBM System/3X0 systems (and EBCDIC) were horrors, though POWER & PowerPC were very interesting for me. ] My first assembly language was Z80, though, which spoiled me for the more primitive CPUs like 6502.
I still maintain some respect for the old iron that could seemingly gracefully handle 200+ users, many of them hammering the system with compile jobs, Mandlebrot set "renders", or other geek-driven nonsense, without going off into the weeds the way a 2017 system does when you do something trivial like enumerate a large directory of files/folders recursively.
Joseph of Tam (I am) wrote:
If all your concerned is dovecot dot-files, you can place the indices somewhere else other than the user's filesapace.
When I manually created the .subscriptions file(s) in the right places, the error message went away, and the functionality seems to work in SeaMonkey clients.
I wonder if it's a combination of permissions (even though the mail directories are all owned by their respective users), or dovecot settings... 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? I was surprised by the pickiness of the group ownership/permissions issues, though reflecting on things, I can see why you'd at least want some logging by default for those conditions.
His Timoness boomed:
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 [...]
I don't know about this. Anyway, can't apply this patch since it likely fails elsewhere.
Fair enough. I knew this was unlikely to be accepted for multiple reasons, never mind a ferociously high potential-pain:reward ratio.
I'm happy to help in my insignificant way, re: the second patch.
DO many people use filesystem quotas with dovecot much, you think?
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.
I suspect the (heavy) use of procmail on Herr Frankbox is contributing to either some lock "confusion" *OR* triggering dovecot to do "expensive" mbox re-read/syncs or something?
There are mail-mulching scriplets in the global procmail (tied to spamassassin results). Some daintily direct the dross to the /dev/null paradise in the sky. Some "consume" the mail and redirect them to one of two or three folders within mail/, while the "rest" allow procmail to append it to INBOX.
My question is:
Is there is smarter way to do the "delivery" so that the dovecot system is "informed" of an append (or excision), obviating or at least reducing the need to perform more costly re-syncs (or timeouts awaiting a lock break)?
I anticipate a thundering herd declaiming that procmail is the spawn of Satan, Hitler, and He-who-shall-not-be-named. As someone who was responsible for much of them (nearing 10 years ago, now), I don't disagree with that view.
I don't have the budget or mandate to bring slivers of Elysium to this downtrodden backwater of technology. I would expect that any use of procmail with dovecot's "special" mail storage formats would *REQUIRE* the use of "deliver" or some other tool to properly incorporate new mail into a dovecot hive.
My thanks as always, =M=