bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains

[Lars Ingebrigtsen]

(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).