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: Eli Zaretskii <eliz <at> gnu.org>, ncaprisunfan <at> gmail.com, 49261 <at> debbugs.gnu.org
Subject: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains
Date: Thu, 08 Jul 2021 21:53:08 +0200

Michael Albinus <michael.albinus <at> gmx.de> writes:

Hi Lars,

>> I will check tomorrow why these test cases fail, and how to integrate
>> the new lock-file-name-transforms into Tramp.
>
> This remains open for later today, or tomorrow.

This is done. ATM, I've decided not to write an own Tramp handler for
make-lock-file-name, the default function is good enough. But the
infrastructure for such a handler is prepared, when needed.

One point I am missing is to suppress lock files, customised by
users. There is create-lockfiles, but this is all-or-nothing. One idea
we've discussed shortly would be to add a file-lock-mode, similar to the
existing auto-save-mode. Would be useful, but it is restricted to the
current buffer.

Another idea I have is to use the new lock-file-name-transforms user
option. It contains entries (REGEXP REPLACEMENT UNIQUIFY) .

What if we allow REPLACEMENT to be nil, meaning that there shoudn't be
file locks for files matching REGEXP? An entry
("\\`/[^/]*:\\([^/]*/\\)*\\([^/]*\\)\\'") of that variable would
suppress file locks for remote files then.

A similar meaning could be offered for auto-save-file-name-transforms.

Best regards, Michael.

Previous Next

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