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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 62614 in the body.
You can then email your comments to 62614 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Yuri D'Elia <wavexx <at> thregr.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Tramp attempts to remove lock file with
 'remote-file-name-inhibit-locks t
Date: Sun, 02 Apr 2023 15:28:21 +0200

I have the following configuration to reduce remote latency while
saving, where the interesting tidbit is 'remote-file-name-inhibit-locks:

(setq tramp-ssh-controlmaster-options "-o ControlMaster=auto"
      remote-file-name-inhibit-cache 300
      remote-file-name-inhibit-locks t)

While editing a remote file via /scp:remote:test.txt I see the following
warning pop up:

Warning (unlock-file): Cannot remove lock file for /scp:remote:test.txt, ignored

because the lock file hasn't been created in the first place. I guess we
shouldn't attempt to unlock if there was no lock to begin with.


In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.16.0, Xaw scroll bars) of 2023-04-01 built on t14g2
Repository revision: 4bd1fc59664273c571aba8543940768c68eb336b
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Debian GNU/Linux 12 (bookworm)

Configured using:
 'configure --with-x-toolkit=lucid --with-native-compilation
 --with-tree-sitter --without-gsettings 'CFLAGS=-O3 -flto -march=native
 -pipe ' 'LDFLAGS=-fuse-ld=mold -flto''

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

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

Yuri D'Elia <wavexx <at> thregr.org> writes:

Hi Yuri,

> I have the following configuration to reduce remote latency while
> saving, where the interesting tidbit is 'remote-file-name-inhibit-locks:
>
> (setq tramp-ssh-controlmaster-options "-o ControlMaster=auto"
>       remote-file-name-inhibit-cache 300
>       remote-file-name-inhibit-locks t)
>
> While editing a remote file via /scp:remote:test.txt I see the following
> warning pop up:
>
> Warning (unlock-file): Cannot remove lock file for /scp:remote:test.txt, ignored
>
> because the lock file hasn't been created in the first place. I guess we
> shouldn't attempt to unlock if there was no lock to begin with.

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")

--8<---------------cut here---------------start------------->8---
 -- 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’.
--8<---------------cut here---------------end--------------->8---

It speaks only about creation of remote lock files, and not about
removal. One possible workaround for you would be to eval the following
form, additionally to your settings:

--8<---------------cut here---------------start------------->8---
(fset #'tramp-handle-unlock-file #'ignore)
--8<---------------cut here---------------end--------------->8---

Best regards, Michael.

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

From: Yuri D'Elia <wavexx <at> thregr.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 62614 <at> debbugs.gnu.org
Subject: Re: bug#62614: Tramp attempts to remove lock file with
 'remote-file-name-inhibit-locks t
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?

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

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Yuri D'Elia <wavexx <at> thregr.org>
Cc: 62614 <at> debbugs.gnu.org
Subject: Re: bug#62614: Tramp attempts to remove lock file with
 'remote-file-name-inhibit-locks t
Date: Mon, 03 Apr 2023 11:54:08 +0200

Yuri D'Elia <wavexx <at> thregr.org> writes:

Hi Yuri,

> 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?

Don't know, this behavior is "since ever" (I don't remember a change here).

With Tramp I'm agnostic. Tramp follows the behavior of local files. It
could do it differently, the local behavior could change, whatever.

Opinions?

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

As said, it would be a workaround for your expectations. I won't
document it as global solution.

Best regards, Michael.

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

From: Yuri D'Elia <wavexx <at> thregr.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 62614 <at> debbugs.gnu.org
Subject: Re: bug#62614: Tramp attempts to remove lock file with
 'remote-file-name-inhibit-locks t
Date: Mon, 03 Apr 2023 12:01:58 +0200

On Mon, Apr 03 2023, Michael Albinus wrote:
> Don't know, this behavior is "since ever" (I don't remember a change here).
>
> With Tramp I'm agnostic. Tramp follows the behavior of local files. It
> could do it differently, the local behavior could change, whatever.
>
> Opinions?

I fully agree with you that it should follow the behavior of local files
too, so I wouldn't change anything here _just_ for tramp.

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

From: Yuri D'Elia <wavexx <at> thregr.org>
To: Michael Albinus <michael.albinus <at> gmx.de>, 62614 <at> debbugs.gnu.org
Subject: Re: bug#62614: Tramp attempts to remove lock file with
 'remote-file-name-inhibit-locks t
Date: Mon, 03 Apr 2023 12:17:06 +0200

On Mon, Apr 03 2023, Yuri D'Elia wrote:
> On Mon, Apr 03 2023, Michael Albinus wrote:
>> Don't know, this behavior is "since ever" (I don't remember a change here).
>>
>> With Tramp I'm agnostic. Tramp follows the behavior of local files. It
>> could do it differently, the local behavior could change, whatever.
>>
>> Opinions?
>
> I fully agree with you that it should follow the behavior of local files
> too, so I wouldn't change anything here _just_ for tramp.

Thinking loudly, if we inhibit lock creation, what's your opinion on the
unlock warning (for the generic local case)?

IMHO if lock creation is inhibited, we could still attempt to remove the
lock to keep the old behavior, but then the warning shouldn't be
generated as you don't expect the lock to exist in the normal case.

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

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

Yuri D'Elia <wavexx <at> thregr.org> writes:

Hi Yuri,

>> I fully agree with you that it should follow the behavior of local files
>> too, so I wouldn't change anything here _just_ for tramp.
>
> Thinking loudly, if we inhibit lock creation, what's your opinion on the
> unlock warning (for the generic local case)?
>
> IMHO if lock creation is inhibited, we could still attempt to remove the
> lock to keep the old behavior, but then the warning shouldn't be
> generated as you don't expect the lock to exist in the normal case.

That might be an option. But it wouldn't fix your use case, where you
try to avoid the file locking machinery for remote files at all.

Best regards, Michael.

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.

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

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

> Cc: 62614 <at> debbugs.gnu.org
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Date: Mon, 03 Apr 2023 11:54:08 +0200
> 
> Yuri D'Elia <wavexx <at> thregr.org> writes:
> 
> Hi Yuri,
> 
> > 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?
> 
> Don't know, this behavior is "since ever" (I don't remember a change here).
> 
> With Tramp I'm agnostic. Tramp follows the behavior of local files. It
> could do it differently, the local behavior could change, whatever.
> 
> Opinions?

How about trying to remove the lock file, but if creation of lock
files is disabled, suppressing the warning?

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

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

On Mon, Apr 03 2023, Michael Albinus wrote:
>> IMHO if lock creation is inhibited, we could still attempt to remove the
>> lock to keep the old behavior, but then the warning shouldn't be
>> generated as you don't expect the lock to exist in the normal case.
>
> That might be an option. But it wouldn't fix your use case, where you
> try to avoid the file locking machinery for remote files at all.

No, but it would fix an unexpected warning for both tramp and local
files, which I think is beneficial.

On Mon, Apr 03 2023, Eli Zaretskii wrote:
> How about trying to remove the lock file, but if creation of lock
> files is disabled, suppressing the warning?

As above.

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

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

[Message part 1 (text/plain, inline)]

Yuri D'Elia <wavexx <at> thregr.org> writes:

Hi Yuri & Eli,

> On Mon, Apr 03 2023, Michael Albinus wrote:
>>> IMHO if lock creation is inhibited, we could still attempt to remove the
>>> lock to keep the old behavior, but then the warning shouldn't be
>>> generated as you don't expect the lock to exist in the normal case.
>>
>> That might be an option. But it wouldn't fix your use case, where you
>> try to avoid the file locking machinery for remote files at all.
>
> No, but it would fix an unexpected warning for both tramp and local
> files, which I think is beneficial.
>
> On Mon, Apr 03 2023, Eli Zaretskii wrote:
>> How about trying to remove the lock file, but if creation of lock
>> files is disabled, suppressing the warning?
>
> As above.

See appended patch. Shall it go to the emacs-29 or master branch?

Best regards, Michael.

[Message part 2 (text/x-patch, attachment)]

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

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

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  62614 <at> debbugs.gnu.org
> Date: Mon, 03 Apr 2023 18:32:25 +0200
> 
> > On Mon, Apr 03 2023, Michael Albinus wrote:
> >>> IMHO if lock creation is inhibited, we could still attempt to remove the
> >>> lock to keep the old behavior, but then the warning shouldn't be
> >>> generated as you don't expect the lock to exist in the normal case.
> >>
> >> That might be an option. But it wouldn't fix your use case, where you
> >> try to avoid the file locking machinery for remote files at all.
> >
> > No, but it would fix an unexpected warning for both tramp and local
> > files, which I think is beneficial.
> >
> > On Mon, Apr 03 2023, Eli Zaretskii wrote:
> >> How about trying to remove the lock file, but if creation of lock
> >> files is disabled, suppressing the warning?
> >
> > As above.
> 
> See appended patch.

LGTM, thanks.

> Shall it go to the emacs-29 or master branch?

Master, please.

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

From: Yuri D'Elia <wavexx <at> thregr.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62614 <at> debbugs.gnu.org, Michael Albinus <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 20:50:09 +0200

On Mon, Apr 03 2023, Eli Zaretskii wrote:
>> > On Mon, Apr 03 2023, Eli Zaretskii wrote:
>> >> How about trying to remove the lock file, but if creation of lock
>> >> files is disabled, suppressing the warning?
>> >
>> > As above.
>>
>> See appended patch.
>
> LGTM, thanks.
>
>> Shall it go to the emacs-29 or master branch?
>
> Master, please.

As for this specific bug report, I'd close it as "fixed".
The spurious warning was definitely my main complaint.

As for the extra attempt to remove the remote file, I can't think of
anything better at this moment than manually fset'ing the function.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Yuri D'Elia <wavexx <at> thregr.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 62614-done <at> debbugs.gnu.org
Subject: Re: bug#62614: Tramp attempts to remove lock file with
 'remote-file-name-inhibit-locks t
Date: Tue, 04 Apr 2023 09:55:12 +0200

Version: 30.1

Yuri D'Elia <wavexx <at> thregr.org> writes:

Hi Yuri,

>>> >> How about trying to remove the lock file, but if creation of lock
>>> >> files is disabled, suppressing the warning?
>>> >
>>> > As above.
>>>
>>> See appended patch.
>>
>> LGTM, thanks.
>>
>>> Shall it go to the emacs-29 or master branch?
>>
>> Master, please.
>
> As for this specific bug report, I'd close it as "fixed".
> The spurious warning was definitely my main complaint.

Pushed to master, closing.

Best regards, Michael.

Previous Next

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