bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#70900: 30.0.50; tramp complains "File error: Cannot remove lock file


From: Dmitry Gutov
Subject: 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
User-agent: Mozilla Thunderbird

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]