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

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

bug#62614: Tramp attempts to remove lock file with 'remote-file-name-inh


From: Michael Albinus
Subject: bug#62614: Tramp attempts to remove lock file with 'remote-file-name-inhibit-locks t
Date: Mon, 03 Apr 2023 10:35:42 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Yuri D'Elia <wavexx@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.





reply via email to

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