GNU bug report logs - #49261
28.0.50; File Locking Breaks Presumptuous Toolchains

Previous Next

Full log

View this message in rfc822 format

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Mallchad Skeghyeph <ncaprisunfan <at> gmail.com>, 49261 <at> debbugs.gnu.org
Subject: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains
Date: Thu, 01 Jul 2021 18:57:12 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

Hi Lars,

> Yes, this is a question that comes up from time to time, and I don't
> think we've documented in a comprehensive way how to make Emacs not
> write anything in the directories it visits.
>
> For auto-save files, that's auto-save-file-name-transforms.
> For backup files, that's backup-directory-alist.
> For lock files, they can be switched off with create-lockfiles.
>
> Would it make sense to allow the user to control where the lockfiles are
> written?  The lockfiles are symlinks, so it should theoretically be
> possible to have them elsewhere without being any racier than the code
> currently is, I think.
>
> Any opinions?

Thinking about, it makes much sense to write the lockfile into the same
directory as the file it locks. Think about mounted directories. If
there is, for example, an NFS server which exports home directories, and
you are editing /home/user/.emacs with different Emacs instances on
different machines, where /home/user is mounted, you want to protect
~/.emacs for write access from any Emacs instance when needed.

A similar case would be for remote files, where a file could also be
locked for access with Emacs from different machines, which use Tramp.

Note, that file lock does not exist yet for remote files, but as Eli
said, we want this feature.

So the very recommended default lock file name shall be what we have
now. We could give the user a configuration variable to change this
behaviour, but with explicit warning about consequences.

Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.