[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains

From: Lars Ingebrigtsen
Subject: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains
Date: Thu, 01 Jul 2021 12:55:55 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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

Mallchad Skeghyeph <ncaprisunfan@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).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]