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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yuri D'Elia <wavexx <at> thregr.org>
Cc: 62614 <at> debbugs.gnu.org, michael.albinus <at> gmx.de
Subject: Re: bug#62614: Tramp attempts to remove lock file with
 'remote-file-name-inhibit-locks t
Date: Mon, 03 Apr 2023 17:10:26 +0300

> Cc: 62614 <at> debbugs.gnu.org
> From: Yuri D'Elia <wavexx <at> 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.

Previous Next

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