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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 62614@debbugs.gnu.org
> From: Yuri D'Elia <wavexx@thregr.org>
> Date: Mon, 03 Apr 2023 11:19:19 +0200
> 
> 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?

Yes, because a lock file could be created before the option to avoid
them was set.