Derek Martin wrote in <20200512021313.ge20...@bladeshadow.org>: |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
Minus that dotlocking applies to local MBOX delivery only. And minus comparison to the quite complicated local delivery pipe chains that many of you seem to use. And also minus the very long backing store synchronizations that many use, the dotlock file may even never reach backing store. That reminds me that the mailer i maintain does not use fsync() on mailboxes, also something i never thought could happen in real life. |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. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
