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

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

[Dmitry Gutov]

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

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

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Dmitry Gutov <dmitry@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.

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

[Eli Zaretskii]

> Cc: 70900@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@gnu.org>
> 
> Dmitry Gutov <dmitry@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.

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

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@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.

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

[Dmitry Gutov]

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.

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

[Dmitry Gutov]

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.

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

[Dmitry Gutov]

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.

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

[Eli Zaretskii]

> Date: Mon, 13 May 2024 14:30:06 +0300
> Cc: 70900@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@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.

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

[Dmitry Gutov]

On 13/05/2024 18:22, Eli Zaretskii wrote:
>> Date: Mon, 13 May 2024 14:30:06 +0300
>> Cc: 70900@debbugs.gnu.org
>> From: Dmitry Gutov <dmitry@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.

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

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Dmitry Gutov <dmitry@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.

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

[Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Version: 30.1

Dmitry Gutov <dmitry@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.

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

[Dmitry Gutov]

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.