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

Previous Next

Full log

Message #26 received at 49261 <at> debbugs.gnu.org (full text, mbox):

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

(Please keep the debbugs address in the CCs -- otherwise the message
won't reach the bug tracker.)

Mallchad Skeghyeph <ncaprisunfan <at> gmail.com> writes:

>  ...even if the lock files are symlinks (which they not necessarily
>  are), we need to handle the case of several files with identical
>  basenames in different directories.  (Their being symlinks is
>  unimportant, because the target of the symlink doesn't exist.)
>
> Actually, is there even a good reason to keep relying on symlinks in the future?
> Considering that.. ahem, some Operating Systems cannot do symlinks for the
> user?
> If it were treated as a normal file you could load it up with whatever metadata
> you want.

Using a normal file should also work, I think?  But it'd be slightly
less efficient on some common popular file systems.

>  Or just use the UNIIFY logic from auto-save-file-name-transforms
>  unconditionally...
>
> It seems most of `make-auto-save-file-name` makes very little assumptions 
> about how we're modifying the file, actually,
> so it shouldn't be too too problematic to make it work for both.
> Though, I would like an optional single variable for a directory for both,
> as oppose to a slightly opaqueregex.
>
>  Remote, I think, otherwise the lock can be easily ignored from another
>  machine.
>
> Yes. I think we need to keep compatibility with the current lock, if its noticed. 
> Remote or local.
> In the case of remote files, we'd have to assume others might be using the
> current 
> lock behaviour.

Remote files are a problem, but what to do here would be up to the user
(as it is with autosave files).

Previous Next

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