bug#62614: Tramp attempts to remove lock file with 'remote-file-name-inhibit-locks t

[Yuri D'Elia]

On Mon, Apr 03 2023, Michael Albinus wrote:
> Tramp behaves like with local lock files. Imagine, you have a local file
> ~/test with a lock file (a symbolic link) ~/.#test -> something. Set
> create-lock-files to nil. Start editing the local file ~/test, and save
> it. The local lock file ~/.#test is removed.
>
> And that's also what's documented, see (info "(elisp) File Locks")
>
>  -- User Option: remote-file-name-inhibit-locks
>      You can prevent the creation of remote lock files by setting the
>      variable ‘remote-file-name-inhibit-locks’ to ‘t’.
>
>
> It speaks only about creation of remote lock files, and not about
> removal.

Mmmh, maybe it should be mentioned explicitly. For me, "inhibit-locks"
meant inhibiting both creation and removal.

But even for local files, why the unlock is done? For cleanup?

> One possible workaround for you would be to eval the following form,
> additionally to your settings:
>
> (fset #'tramp-handle-unlock-file #'ignore)

Looking at the definition of #'tramp-handle-unlock-file, it does
actually look the most reasonable thing to do, but somehow having to
fset an internal function doesn't feel right, but I don't have a better
proposal since we don't have any setting that inhibit lock handling
completely.

I went with this configuration for a long time, actually. I never
noticed this behavior, because I never had remote lock files to begin
with. Only recently with the warning buffer displayed on errors I
started to see it.