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 <dmitry@gutov.dev>]

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.