GNU bug report logs - #70900
30.0.50; tramp complains "File error: Cannot remove lock file for /ssh:..." on every save when remote-file-name-inhibit-locks is non-nil

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 70900 in the body.
You can then email your comments to 70900 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: Dmitry Gutov <dmitry <at> gutov.dev>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; tramp complains "File error: Cannot remove lock file for
 /ssh:..." on every save when remote-file-name-inhibit-locks is non-nil
Date: Mon, 13 May 2024 04:03:43 +0300

1. (setq remote-file-name-inhibit-locks t)
2. Open some file remotely, lightly edit and save it.
3. See this message in the Messages buffer.

BTW, I'm surprised this variable isn't mentioned in Tramp's FAQ (the
performance section in particular). It would also make sense to switch
it on by default - it has a noticeable effect on performance.

In GNU Emacs 30.0.50 (build 7, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.18.0, Xaw scroll bars) of 2024-05-12 built on potemkin
Repository revision: b20d4ab374fb9b3c80b968df6acd6444f763bd40
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12302000
System Description: Ubuntu 23.10

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 70900 <at> debbugs.gnu.org
Subject: Re: bug#70900: 30.0.50; tramp complains "File error: Cannot remove
 lock file for /ssh:..." on every save when remote-file-name-inhibit-locks
 is non-nil
Date: Mon, 13 May 2024 07:56:29 +0200

Dmitry Gutov <dmitry <at> gutov.dev> writes:

Hi Dmitry,

> 1. (setq remote-file-name-inhibit-locks t)
> 2. Open some file remotely, lightly edit and save it.
> 3. See this message in the Messages buffer.

The description of remote-file-name-inhibit-locks says "Whether to
create file locks for remote files.". And this is what Tramp
does. Nothing said about checking/removing of lock files.

If we want to suppress these actions as well, we shall agree about, and
change the doc. Eli?

> BTW, I'm surprised this variable isn't mentioned in Tramp's FAQ (the
> performance section in particular).

???

In the Tramp manual, node "Frequently Asked Questions", item "How to
speed up TRAMP?", there is

--8<---------------cut here---------------start------------->8---
        − Disable file locks.  Set ‘remote-file-name-inhibit-locks’ to
          ‘t’ if you know that different Emacs sessions are not
          modifying the same remote file.
--8<---------------cut here---------------end--------------->8---

> It would also make sense to switch it on by default - it has a
> noticeable effect on performance.

No. File locks are an essential part of Emacs. Disabling them has the
potential to damage something (see above), so it shall be decided by the user.

Best regards, Michael.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: dmitry <at> gutov.dev, 70900 <at> debbugs.gnu.org
Subject: Re: bug#70900: 30.0.50;
 tramp complains "File error: Cannot remove lock file for /ssh:..." on
 every save when remote-file-name-inhibit-locks is non-nil
Date: Mon, 13 May 2024 09:54:52 +0300

> Cc: 70900 <at> debbugs.gnu.org
> Date: Mon, 13 May 2024 07:56:29 +0200
> From:  Michael Albinus via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Dmitry Gutov <dmitry <at> gutov.dev> writes:
> 
> Hi Dmitry,
> 
> > 1. (setq remote-file-name-inhibit-locks t)
> > 2. Open some file remotely, lightly edit and save it.
> > 3. See this message in the Messages buffer.
> 
> The description of remote-file-name-inhibit-locks says "Whether to
> create file locks for remote files.". And this is what Tramp
> does. Nothing said about checking/removing of lock files.
> 
> If we want to suppress these actions as well, we shall agree about, and
> change the doc. Eli?

I think making the failure to remove be silent in this case is enough.
If the user sets this variable to t, they are not interested in
failures to remove lock files, even if it's for reasons other than
"file does not exist".

IOW, it's okay to try to remove lock files, but if that fails, Emacs
should not display any error messages.

> > It would also make sense to switch it on by default - it has a
> > noticeable effect on performance.
> 
> No. File locks are an essential part of Emacs. Disabling them has the
> potential to damage something (see above), so it shall be decided by the user.

Agreed.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dmitry <at> gutov.dev, 70900 <at> debbugs.gnu.org
Subject: Re: bug#70900: 30.0.50; tramp complains "File error: Cannot remove
 lock file for /ssh:..." on every save when remote-file-name-inhibit-locks
 is non-nil
Date: Mon, 13 May 2024 09:28:41 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi Eli,

>> The description of remote-file-name-inhibit-locks says "Whether to
>> create file locks for remote files.". And this is what Tramp
>> does. Nothing said about checking/removing of lock files.
>>
>> If we want to suppress these actions as well, we shall agree about, and
>> change the doc. Eli?
>
> I think making the failure to remove be silent in this case is enough.
> If the user sets this variable to t, they are not interested in
> failures to remove lock files, even if it's for reasons other than
> "file does not exist".
>
> IOW, it's okay to try to remove lock files, but if that fails, Emacs
> should not display any error messages.

Done, pushed to master. Anything else, Dmitry?

Best regards, Michael.

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Michael Albinus <michael.albinus <at> gmx.de>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 70900 <at> debbugs.gnu.org
Subject: Re: bug#70900: 30.0.50; tramp complains "File error: Cannot remove
 lock file for /ssh:..." on every save when remote-file-name-inhibit-locks is
 non-nil
Date: Mon, 13 May 2024 14:11:55 +0300

Hi Michael,

On 13/05/2024 10:28, Michael Albinus wrote:
>>> The description of remote-file-name-inhibit-locks says "Whether to
>>> create file locks for remote files.". And this is what Tramp
>>> does. Nothing said about checking/removing of lock files.
>>>
>>> If we want to suppress these actions as well, we shall agree about, and
>>> change the doc. Eli?
>> I think making the failure to remove be silent in this case is enough.
>> If the user sets this variable to t, they are not interested in
>> failures to remove lock files, even if it's for reasons other than
>> "file does not exist".
>>
>> IOW, it's okay to try to remove lock files, but if that fails, Emacs
>> should not display any error messages.
> Done, pushed to master. Anything else, Dmitry?

It's a good enough resolution for me. Thank you.

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>, Michael Albinus <michael.albinus <at> gmx.de>
Cc: 70900 <at> debbugs.gnu.org
Subject: Re: bug#70900: 30.0.50; tramp complains "File error: Cannot remove
 lock file for /ssh:..." on every save when remote-file-name-inhibit-locks is
 non-nil
Date: Mon, 13 May 2024 14:30:06 +0300

On 13/05/2024 09:54, Eli Zaretskii wrote:
>>> It would also make sense to switch it on by default - it has a
>>> noticeable effect on performance.
>> No. File locks are an essential part of Emacs. Disabling them has the
>> potential to damage something (see above), so it shall be decided by the user.
> Agreed.

In this aspect I'm commenting as someone who sees user complaints from 
time to time about how VS Code or etc are faster at remote development 
than Emacs, and now saw this myself. This particular issue looks like a 
speed bump that could be removed for good improvement in basic latency.

But perhaps it's better approached by optimizing in other places.

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 70900 <at> debbugs.gnu.org
Subject: Re: bug#70900: 30.0.50; tramp complains "File error: Cannot remove
 lock file for /ssh:..." on every save when remote-file-name-inhibit-locks is
 non-nil
Date: Mon, 13 May 2024 14:30:18 +0300

On 13/05/2024 08:56, Michael Albinus wrote:
>> BTW, I'm surprised this variable isn't mentioned in Tramp's FAQ (the
>> performance section in particular).
> ???
> 
> In the Tramp manual, node "Frequently Asked Questions", item "How to
> speed up TRAMP?", there is
> 
> --8<---------------cut here---------------start------------->8---
>          − Disable file locks.  Set ‘remote-file-name-inhibit-locks’ to
>            ‘t’ if you know that different Emacs sessions are not
>            modifying the same remote file.
> --8<---------------cut here---------------end--------------->8---

Yes, sorry, I see it now.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 70900 <at> debbugs.gnu.org, michael.albinus <at> gmx.de
Subject: Re: bug#70900: 30.0.50; tramp complains "File error: Cannot remove
 lock file for /ssh:..." on every save when remote-file-name-inhibit-locks is
 non-nil
Date: Mon, 13 May 2024 18:22:06 +0300

> Date: Mon, 13 May 2024 14:30:06 +0300
> Cc: 70900 <at> debbugs.gnu.org
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> On 13/05/2024 09:54, Eli Zaretskii wrote:
> >>> It would also make sense to switch it on by default - it has a
> >>> noticeable effect on performance.
> >> No. File locks are an essential part of Emacs. Disabling them has the
> >> potential to damage something (see above), so it shall be decided by the user.
> > Agreed.
> 
> In this aspect I'm commenting as someone who sees user complaints from 
> time to time about how VS Code or etc are faster at remote development 
> than Emacs, and now saw this myself.

VS Code is written for people who own the computer and only have a
single session active at all times (that's how Visual Studio works,
remember?), so they don't need to lock file.  People who use Emacs in
the same way could indeed disable file locking.  But Emacs itself
cannot know whether this is the case, and given the proliferation of
Emacs usage patterns whereby people use the same session locally and
from a remote machine, we cannot disable file locking by default, IMO.

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70900 <at> debbugs.gnu.org, michael.albinus <at> gmx.de
Subject: Re: bug#70900: 30.0.50; tramp complains "File error: Cannot remove
 lock file for /ssh:..." on every save when remote-file-name-inhibit-locks is
 non-nil
Date: Tue, 14 May 2024 01:31:01 +0300

On 13/05/2024 18:22, Eli Zaretskii wrote:
>> Date: Mon, 13 May 2024 14:30:06 +0300
>> Cc: 70900 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dmitry <at> gutov.dev>
>>
>> On 13/05/2024 09:54, Eli Zaretskii wrote:
>>>>> It would also make sense to switch it on by default - it has a
>>>>> noticeable effect on performance.
>>>> No. File locks are an essential part of Emacs. Disabling them has the
>>>> potential to damage something (see above), so it shall be decided by the user.
>>> Agreed.
>>
>> In this aspect I'm commenting as someone who sees user complaints from
>> time to time about how VS Code or etc are faster at remote development
>> than Emacs, and now saw this myself.
> 
> VS Code is written for people who own the computer and only have a
> single session active at all times (that's how Visual Studio works,
> remember?), so they don't need to lock file.  People who use Emacs in
> the same way could indeed disable file locking.  But Emacs itself
> cannot know whether this is the case, and given the proliferation of
> Emacs usage patterns whereby people use the same session locally and
> from a remote machine, we cannot disable file locking by default, IMO.

But the variable only affects remote editing.

Anyway, you are mostly correct, I think. Except VS Code these days also 
touts "full featured" remote development, so editing the same files by 
two different users wouldn't be out of the question. But most of those 
use case fall under working in an personal virtual machine or container 
(geographically remote or on the same host), so those issues shouldn't 
crop up.

Still, it would be great if tramp could batch more checks to happen at 
once, rather than do them over multiple round-trips. Though that would 
mean having to maintain a separate "remote" version of 
'basic-save-buffer', I guess.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 70900 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#70900: 30.0.50; tramp complains "File error: Cannot remove
 lock file for /ssh:..." on every save when remote-file-name-inhibit-locks
 is non-nil
Date: Wed, 15 May 2024 12:18:56 +0200

Dmitry Gutov <dmitry <at> gutov.dev> writes:

Hi Dmitry,

> Still, it would be great if tramp could batch more checks to happen at
> once, rather than do them over multiple round-trips. Though that would
> mean having to maintain a separate "remote" version of
> 'basic-save-buffer', I guess.

Tramp tries to do this, but it is limited. It sees the remote side on
the perspective of a primitive file operation it has an implementation
for, see the list on (info "(elisp) Magic File Names")

And yes, 'basic-save-buffer' doesn't belong to this list.

Tramp tries to combine several actions in order to decrease the number
of roundtrips. And it uses caches. But all of this is mimited.

Tramp offers s special trace mode which shows you the external commands
it sends per primitive file operation. Call something like

--8<---------------cut here---------------start------------->8---
# emacs -Q --eval '(setq tramp-debug-command-messages t)' /ssh::
--8<---------------cut here---------------end--------------->8---

In the debug buffer, there are messages of level 4 (entering a primitive
file operation), level 5 (exiting the same operation), and level 6 (the
remote commands Tramp emits). Like

--8<---------------cut here---------------start------------->8---
12:11:26.513974 tramp-sh-handle-file-exists-p (4) # Running `(file-exists-p "/ssh:gandalf:/net/ford/albinus/Books.org")' ...
12:11:26.514344 tramp-send-command (6) # test -e /net/ford/albinus/Books.org 2>/dev/null; echo tramp_exit_status $?
12:11:26.530496 tramp-wait-for-regexp (6) #
tramp_exit_status 0
///fd26d4d0719c81d3c6e45f14adefee05#$
12:11:26.530742 tramp-sh-handle-file-exists-p (5) # Running `(file-exists-p "/ssh:gandalf:/net/ford/albinus/Books.org")' ... t
--8<---------------cut here---------------end--------------->8---

This is my tool to analyze. Several optimiztations have been performed
already, but there is still room for improvement, proposals/patches
welcome.

Best regards, Michael.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 70900-done <at> debbugs.gnu.org
Subject: Re: bug#70900: 30.0.50; tramp complains "File error: Cannot remove
 lock file for /ssh:..." on every save when remote-file-name-inhibit-locks
 is non-nil
Date: Wed, 15 May 2024 12:20:48 +0200

Version: 30.1

Dmitry Gutov <dmitry <at> gutov.dev> writes:

> Hi Michael,

Hi Dmitry,

>>> IOW, it's okay to try to remove lock files, but if that fails, Emacs
>>> should not display any error messages.
>>
>> Done, pushed to master. Anything else, Dmitry?
>
> It's a good enough resolution for me. Thank you.

Thanks for the feedback. Closing the bug.

Best regards, Michael.

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 70900 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#70900: 30.0.50; tramp complains "File error: Cannot remove
 lock file for /ssh:..." on every save when remote-file-name-inhibit-locks is
 non-nil
Date: Mon, 20 May 2024 03:08:40 +0300

Hi Michael,

On 15/05/2024 13:18, Michael Albinus wrote:
> In the debug buffer, there are messages of level 4 (entering a primitive
> file operation), level 5 (exiting the same operation), and level 6 (the
> remote commands Tramp emits). Like
> 
> --8<---------------cut here---------------start------------->8---
> 12:11:26.513974 tramp-sh-handle-file-exists-p (4) # Running `(file-exists-p "/ssh:gandalf:/net/ford/albinus/Books.org")' ...
> 12:11:26.514344 tramp-send-command (6) # test -e /net/ford/albinus/Books.org 2>/dev/null; echo tramp_exit_status $?
> 12:11:26.530496 tramp-wait-for-regexp (6) #
> tramp_exit_status 0
> ///fd26d4d0719c81d3c6e45f14adefee05#$
> 12:11:26.530742 tramp-sh-handle-file-exists-p (5) # Running `(file-exists-p "/ssh:gandalf:/net/ford/albinus/Books.org")' ... t
> --8<---------------cut here---------------end--------------->8---
> 
> This is my tool to analyze. Several optimiztations have been performed
> already, but there is still room for improvement, proposals/patches
> welcome.

Thank you, I've sent a message to bug#56342, which seems to have some 
pre-existing discussion on the subject.

Previous Next

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