On Mon, May 11, 2020 at 08:38:19PM +0200, Steffen Nurpmeso wrote: > Vincent Lefevre wrote in > <20200510204809.ga71...@zira.vinc17.org>: > |Related to commit 7bd57bc3c24adf97f1f57bd6bb2fd18347f8cbbd, is > |dotlocking still used nowadays? > > I find yes. Or at least last i looked, some MTAs aka MDA or > whatever the right name is (LDA? postfix > (configurable), i think OpenBSDs mail.local (which saw heavy > modifications lately though)) create these files, and then i think > it seems sensible to embed in this locking strategy.
IIRC most of the MDAs support multiple locking mechanisms, and at
least some of them use multiple mechanism simultaneously. But dot
locking is slow, which probably doesn't matter on your home e-mail
server, but would matter on a mail server that handles millions of
messages a day... And it may still be unreliable, depending on the
exact mix of things you have. If you have one mechanism that's known
to work reliably across your whole mail system, you should use that,
and hope that it's not dot locking.
> |Let's recall that dotlocking alone is not safe with some file systems,
> |such as NFS, since even if the client has an exclusive access to the
> |mailbox file, there is no guarantee that the synchronization will be
> |done before another program accesses the mailbox. In short, a working
> |fcntl locking is needed. But if it is available, then dotlocking is
> |useless. So, IMHO, if still supported, dotlocking should just be seen
> |as a fallback, and if mutt_dotlock cannot be installed with the right
> |permissions, the installation of Mutt should not fail.
>
> I do not think so. fcntl is "the new way"
I don't think anything that's been available for > 20 years in the
world of computing can be considered "new" anymore... =8^)
> and used anyway (for my MUA), but embedding into the scheme used by
> others is crucial, and as long as they use dotlock files for
> synchronization i will use it.
All MDAs that are still supported use POSIX locking. So dot locking
is superfluous and only slows you down.
But let's not also forget that NFS is not the only problem. There are
a wide array of file systems, and you can't be sure they implement
your favorite locking mechanism. But, t's more likely that if POSIX
locking doesn't work on those, since it's one call and its interface
expects that it might not be implemented everywhere, you'll likely
just get EINVAL back, whereas a dot lock might be more likely to fail
silently (as it did under Linux).
> NFS locking is "now" ok i have heard (here "now" is maybe almost two
> decades),
That depends on what you mean:
If you're on Linux, and:
- If you mean POSIX locking, yes. It's worked reliably since at
least as far back as 2.4, and I believe earlier. (There was a
really old bug in lockd that broke it, but that's been fixed for
about 20 years or something)... AFAIK there have been no reported
bugs with it since.
- If you mean dot locking... In Linux it's been "OK" since 2.6.5,
if all of your clients and server are running Linux and NFSv3 or
greater. Maybe. :)
If you mean NOT Linux, or you have a mix of things... file locking
over NFS is a horror show, in general, and if your environment is not
100% homogenous all bets are off. There have been various bugs in the
NFS and/or locking implementations of pretty much every platform ever,
and they don't generally interoperate well.
If you have NFS in the picture, and your site isn't 100% homogenous,
you'd better know exactly what's supported reliably by all of them,
and it's pretty much guaranteed to be POSIX locking, by now--it's kind
of the point of POSIX. Otherwise, you may as well assume data
corruption is guaranteed. Better to avoid accessing your mail spool
over NFS, or use Maildir.
I'm not sure that it makes sense to remove dot locking from Mutt
entirely, but it probably does make sense to turn it off unless
explicitly requested.
--
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail due to spam prevention. Sorry for the inconvenience.
signature.asc
Description: PGP signature
