* bug#62614: Tramp attempts to remove lock file with 'remote-file-name-inhibit-locks t
@ 2023-04-02 13:28 Yuri D'Elia
2023-04-03 8:35 ` Michael Albinus
0 siblings, 1 reply; 14+ messages in thread
From: Yuri D'Elia @ 2023-04-02 13:28 UTC (permalink / raw)
To: 62614
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.
In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.16.0, Xaw scroll bars) of 2023-04-01 built on t14g2
Repository revision: 4bd1fc59664273c571aba8543940768c68eb336b
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Debian GNU/Linux 12 (bookworm)
Configured using:
'configure --with-x-toolkit=lucid --with-native-compilation
--with-tree-sitter --without-gsettings 'CFLAGS=-O3 -flto -march=native
-pipe ' 'LDFLAGS=-fuse-ld=mold -flto''
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#62614: Tramp attempts to remove lock file with 'remote-file-name-inhibit-locks t 2023-04-02 13:28 bug#62614: Tramp attempts to remove lock file with 'remote-file-name-inhibit-locks t Yuri D'Elia @ 2023-04-03 8:35 ` Michael Albinus 2023-04-03 9:19 ` Yuri D'Elia 0 siblings, 1 reply; 14+ messages in thread From: Michael Albinus @ 2023-04-03 8:35 UTC (permalink / raw) To: Yuri D'Elia; +Cc: 62614 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62614: Tramp attempts to remove lock file with 'remote-file-name-inhibit-locks t 2023-04-03 8:35 ` Michael Albinus @ 2023-04-03 9:19 ` Yuri D'Elia 2023-04-03 9:54 ` Michael Albinus 2023-04-03 14:10 ` Eli Zaretskii 0 siblings, 2 replies; 14+ messages in thread From: Yuri D'Elia @ 2023-04-03 9:19 UTC (permalink / raw) To: Michael Albinus; +Cc: 62614 On Mon, Apr 03 2023, Michael Albinus wrote: > 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") > > -- 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’. > > > It speaks only about creation of remote lock files, and not about > removal. Mmmh, maybe it should be mentioned explicitly. For me, "inhibit-locks" meant inhibiting both creation and removal. But even for local files, why the unlock is done? For cleanup? > One possible workaround for you would be to eval the following form, > additionally to your settings: > > (fset #'tramp-handle-unlock-file #'ignore) Looking at the definition of #'tramp-handle-unlock-file, it does actually look the most reasonable thing to do, but somehow having to fset an internal function doesn't feel right, but I don't have a better proposal since we don't have any setting that inhibit lock handling completely. I went with this configuration for a long time, actually. I never noticed this behavior, because I never had remote lock files to begin with. Only recently with the warning buffer displayed on errors I started to see it. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62614: Tramp attempts to remove lock file with 'remote-file-name-inhibit-locks t 2023-04-03 9:19 ` Yuri D'Elia @ 2023-04-03 9:54 ` Michael Albinus 2023-04-03 10:01 ` Yuri D'Elia 2023-04-03 14:14 ` Eli Zaretskii 2023-04-03 14:10 ` Eli Zaretskii 1 sibling, 2 replies; 14+ messages in thread From: Michael Albinus @ 2023-04-03 9:54 UTC (permalink / raw) To: Yuri D'Elia; +Cc: 62614 Yuri D'Elia <wavexx@thregr.org> writes: Hi Yuri, > Mmmh, maybe it should be mentioned explicitly. For me, "inhibit-locks" > meant inhibiting both creation and removal. > > But even for local files, why the unlock is done? For cleanup? Don't know, this behavior is "since ever" (I don't remember a change here). With Tramp I'm agnostic. Tramp follows the behavior of local files. It could do it differently, the local behavior could change, whatever. Opinions? >> One possible workaround for you would be to eval the following form, >> additionally to your settings: >> >> (fset #'tramp-handle-unlock-file #'ignore) > > Looking at the definition of #'tramp-handle-unlock-file, it does > actually look the most reasonable thing to do, but somehow having to > fset an internal function doesn't feel right, but I don't have a better > proposal since we don't have any setting that inhibit lock handling > completely. As said, it would be a workaround for your expectations. I won't document it as global solution. Best regards, Michael. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62614: Tramp attempts to remove lock file with 'remote-file-name-inhibit-locks t 2023-04-03 9:54 ` Michael Albinus @ 2023-04-03 10:01 ` Yuri D'Elia 2023-04-03 10:17 ` Yuri D'Elia 2023-04-03 14:14 ` Eli Zaretskii 1 sibling, 1 reply; 14+ messages in thread From: Yuri D'Elia @ 2023-04-03 10:01 UTC (permalink / raw) To: Michael Albinus; +Cc: 62614 On Mon, Apr 03 2023, Michael Albinus wrote: > Don't know, this behavior is "since ever" (I don't remember a change here). > > With Tramp I'm agnostic. Tramp follows the behavior of local files. It > could do it differently, the local behavior could change, whatever. > > Opinions? I fully agree with you that it should follow the behavior of local files too, so I wouldn't change anything here _just_ for tramp. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62614: Tramp attempts to remove lock file with 'remote-file-name-inhibit-locks t 2023-04-03 10:01 ` Yuri D'Elia @ 2023-04-03 10:17 ` Yuri D'Elia 2023-04-03 10:30 ` Michael Albinus 0 siblings, 1 reply; 14+ messages in thread From: Yuri D'Elia @ 2023-04-03 10:17 UTC (permalink / raw) To: Michael Albinus, 62614 On Mon, Apr 03 2023, Yuri D'Elia wrote: > On Mon, Apr 03 2023, Michael Albinus wrote: >> Don't know, this behavior is "since ever" (I don't remember a change here). >> >> With Tramp I'm agnostic. Tramp follows the behavior of local files. It >> could do it differently, the local behavior could change, whatever. >> >> Opinions? > > I fully agree with you that it should follow the behavior of local files > too, so I wouldn't change anything here _just_ for tramp. Thinking loudly, if we inhibit lock creation, what's your opinion on the unlock warning (for the generic local case)? IMHO if lock creation is inhibited, we could still attempt to remove the lock to keep the old behavior, but then the warning shouldn't be generated as you don't expect the lock to exist in the normal case. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62614: Tramp attempts to remove lock file with 'remote-file-name-inhibit-locks t 2023-04-03 10:17 ` Yuri D'Elia @ 2023-04-03 10:30 ` Michael Albinus 2023-04-03 14:54 ` Yuri D'Elia 0 siblings, 1 reply; 14+ messages in thread From: Michael Albinus @ 2023-04-03 10:30 UTC (permalink / raw) To: Yuri D'Elia; +Cc: 62614 Yuri D'Elia <wavexx@thregr.org> writes: Hi Yuri, >> I fully agree with you that it should follow the behavior of local files >> too, so I wouldn't change anything here _just_ for tramp. > > Thinking loudly, if we inhibit lock creation, what's your opinion on the > unlock warning (for the generic local case)? > > IMHO if lock creation is inhibited, we could still attempt to remove the > lock to keep the old behavior, but then the warning shouldn't be > generated as you don't expect the lock to exist in the normal case. That might be an option. But it wouldn't fix your use case, where you try to avoid the file locking machinery for remote files at all. Best regards, Michael. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62614: Tramp attempts to remove lock file with 'remote-file-name-inhibit-locks t 2023-04-03 10:30 ` Michael Albinus @ 2023-04-03 14:54 ` Yuri D'Elia 2023-04-03 16:32 ` Michael Albinus 0 siblings, 1 reply; 14+ messages in thread From: Yuri D'Elia @ 2023-04-03 14:54 UTC (permalink / raw) To: Michael Albinus, Eli Zaretskii; +Cc: 62614 On Mon, Apr 03 2023, Michael Albinus wrote: >> IMHO if lock creation is inhibited, we could still attempt to remove the >> lock to keep the old behavior, but then the warning shouldn't be >> generated as you don't expect the lock to exist in the normal case. > > That might be an option. But it wouldn't fix your use case, where you > try to avoid the file locking machinery for remote files at all. No, but it would fix an unexpected warning for both tramp and local files, which I think is beneficial. On Mon, Apr 03 2023, Eli Zaretskii wrote: > How about trying to remove the lock file, but if creation of lock > files is disabled, suppressing the warning? As above. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62614: Tramp attempts to remove lock file with 'remote-file-name-inhibit-locks t 2023-04-03 14:54 ` Yuri D'Elia @ 2023-04-03 16:32 ` Michael Albinus 2023-04-03 16:45 ` Eli Zaretskii 0 siblings, 1 reply; 14+ messages in thread From: Michael Albinus @ 2023-04-03 16:32 UTC (permalink / raw) To: Yuri D'Elia; +Cc: Eli Zaretskii, 62614 [-- Attachment #1: Type: text/plain, Size: 843 bytes --] Yuri D'Elia <wavexx@thregr.org> writes: Hi Yuri & Eli, > On Mon, Apr 03 2023, Michael Albinus wrote: >>> IMHO if lock creation is inhibited, we could still attempt to remove the >>> lock to keep the old behavior, but then the warning shouldn't be >>> generated as you don't expect the lock to exist in the normal case. >> >> That might be an option. But it wouldn't fix your use case, where you >> try to avoid the file locking machinery for remote files at all. > > No, but it would fix an unexpected warning for both tramp and local > files, which I think is beneficial. > > On Mon, Apr 03 2023, Eli Zaretskii wrote: >> How about trying to remove the lock file, but if creation of lock >> files is disabled, suppressing the warning? > > As above. See appended patch. Shall it go to the emacs-29 or master branch? Best regards, Michael. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: Type: text/x-patch, Size: 1967 bytes --] diff --git a/lisp/files.el b/lisp/files.el index d325729bf4d..216d31c737b 100644 --- a/lisp/files.el +++ b/lisp/files.el @@ -555,7 +555,7 @@ lock-file-name-transforms :version "28.1") (defcustom remote-file-name-inhibit-locks nil - "Whether to use file locks for remote files." + "Whether to create file locks for remote files." :group 'files :version "28.1" :type 'boolean) diff --git a/lisp/net/tramp.el b/lisp/net/tramp.el index df2f0850b83..4180a32b6d9 100644 --- a/lisp/net/tramp.el +++ b/lisp/net/tramp.el @@ -4585,7 +4585,8 @@ tramp-handle-unlock-file (condition-case err (delete-file lockname) ;; `userlock--handle-unlock-error' exists since Emacs 28.1. - (error (tramp-compat-funcall 'userlock--handle-unlock-error err))))) + (error (and (not (bound-and-true-p remote-file-name-inhibit-locks)) + (tramp-compat-funcall 'userlock--handle-unlock-error err)))))) (defun tramp-handle-load (file &optional noerror nomessage nosuffix must-suffix) "Like `load' for Tramp files." diff --git a/lisp/userlock.el b/lisp/userlock.el index 61f061d3e54..562bc0a0a9f 100644 --- a/lisp/userlock.el +++ b/lisp/userlock.el @@ -206,11 +206,12 @@ ask-user-about-supersession-help ;;;###autoload (defun userlock--handle-unlock-error (error) "Report an ERROR that occurred while unlocking a file." - (display-warning - '(unlock-file) - ;; There is no need to explain that this is an unlock error because - ;; ERROR is a `file-error' condition, which explains this. - (message "%s, ignored" (error-message-string error)) - :warning)) + (when create-lockfiles + (display-warning + '(unlock-file) + ;; There is no need to explain that this is an unlock error because + ;; ERROR is a `file-error' condition, which explains this. + (message "%s, ignored" (error-message-string error)) + :warning))) ;;; userlock.el ends here ^ permalink raw reply related [flat|nested] 14+ messages in thread
* bug#62614: Tramp attempts to remove lock file with 'remote-file-name-inhibit-locks t 2023-04-03 16:32 ` Michael Albinus @ 2023-04-03 16:45 ` Eli Zaretskii 2023-04-03 18:50 ` Yuri D'Elia 0 siblings, 1 reply; 14+ messages in thread From: Eli Zaretskii @ 2023-04-03 16:45 UTC (permalink / raw) To: Michael Albinus; +Cc: wavexx, 62614 > From: Michael Albinus <michael.albinus@gmx.de> > Cc: Eli Zaretskii <eliz@gnu.org>, 62614@debbugs.gnu.org > Date: Mon, 03 Apr 2023 18:32:25 +0200 > > > On Mon, Apr 03 2023, Michael Albinus wrote: > >>> IMHO if lock creation is inhibited, we could still attempt to remove the > >>> lock to keep the old behavior, but then the warning shouldn't be > >>> generated as you don't expect the lock to exist in the normal case. > >> > >> That might be an option. But it wouldn't fix your use case, where you > >> try to avoid the file locking machinery for remote files at all. > > > > No, but it would fix an unexpected warning for both tramp and local > > files, which I think is beneficial. > > > > On Mon, Apr 03 2023, Eli Zaretskii wrote: > >> How about trying to remove the lock file, but if creation of lock > >> files is disabled, suppressing the warning? > > > > As above. > > See appended patch. LGTM, thanks. > Shall it go to the emacs-29 or master branch? Master, please. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62614: Tramp attempts to remove lock file with 'remote-file-name-inhibit-locks t 2023-04-03 16:45 ` Eli Zaretskii @ 2023-04-03 18:50 ` Yuri D'Elia 2023-04-04 7:55 ` Michael Albinus 0 siblings, 1 reply; 14+ messages in thread From: Yuri D'Elia @ 2023-04-03 18:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 62614, Michael Albinus On Mon, Apr 03 2023, Eli Zaretskii wrote: >> > On Mon, Apr 03 2023, Eli Zaretskii wrote: >> >> How about trying to remove the lock file, but if creation of lock >> >> files is disabled, suppressing the warning? >> > >> > As above. >> >> See appended patch. > > LGTM, thanks. > >> Shall it go to the emacs-29 or master branch? > > Master, please. As for this specific bug report, I'd close it as "fixed". The spurious warning was definitely my main complaint. As for the extra attempt to remove the remote file, I can't think of anything better at this moment than manually fset'ing the function. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62614: Tramp attempts to remove lock file with 'remote-file-name-inhibit-locks t 2023-04-03 18:50 ` Yuri D'Elia @ 2023-04-04 7:55 ` Michael Albinus 0 siblings, 0 replies; 14+ messages in thread From: Michael Albinus @ 2023-04-04 7:55 UTC (permalink / raw) To: Yuri D'Elia; +Cc: Eli Zaretskii, 62614-done Version: 30.1 Yuri D'Elia <wavexx@thregr.org> writes: Hi Yuri, >>> >> How about trying to remove the lock file, but if creation of lock >>> >> files is disabled, suppressing the warning? >>> > >>> > As above. >>> >>> See appended patch. >> >> LGTM, thanks. >> >>> Shall it go to the emacs-29 or master branch? >> >> Master, please. > > As for this specific bug report, I'd close it as "fixed". > The spurious warning was definitely my main complaint. Pushed to master, closing. Best regards, Michael. ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62614: Tramp attempts to remove lock file with 'remote-file-name-inhibit-locks t 2023-04-03 9:54 ` Michael Albinus 2023-04-03 10:01 ` Yuri D'Elia @ 2023-04-03 14:14 ` Eli Zaretskii 1 sibling, 0 replies; 14+ messages in thread From: Eli Zaretskii @ 2023-04-03 14:14 UTC (permalink / raw) To: Michael Albinus; +Cc: wavexx, 62614 > Cc: 62614@debbugs.gnu.org > From: Michael Albinus <michael.albinus@gmx.de> > Date: Mon, 03 Apr 2023 11:54:08 +0200 > > Yuri D'Elia <wavexx@thregr.org> writes: > > Hi Yuri, > > > Mmmh, maybe it should be mentioned explicitly. For me, "inhibit-locks" > > meant inhibiting both creation and removal. > > > > But even for local files, why the unlock is done? For cleanup? > > Don't know, this behavior is "since ever" (I don't remember a change here). > > With Tramp I'm agnostic. Tramp follows the behavior of local files. It > could do it differently, the local behavior could change, whatever. > > Opinions? How about trying to remove the lock file, but if creation of lock files is disabled, suppressing the warning? ^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#62614: Tramp attempts to remove lock file with 'remote-file-name-inhibit-locks t 2023-04-03 9:19 ` Yuri D'Elia 2023-04-03 9:54 ` Michael Albinus @ 2023-04-03 14:10 ` Eli Zaretskii 1 sibling, 0 replies; 14+ messages in thread From: Eli Zaretskii @ 2023-04-03 14:10 UTC (permalink / raw) To: Yuri D'Elia; +Cc: 62614, michael.albinus > Cc: 62614@debbugs.gnu.org > From: Yuri D'Elia <wavexx@thregr.org> > Date: Mon, 03 Apr 2023 11:19:19 +0200 > > On Mon, Apr 03 2023, Michael Albinus wrote: > > 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") > > > > -- 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’. > > > > > > It speaks only about creation of remote lock files, and not about > > removal. > > Mmmh, maybe it should be mentioned explicitly. For me, "inhibit-locks" > meant inhibiting both creation and removal. > > But even for local files, why the unlock is done? For cleanup? Yes, because a lock file could be created before the option to avoid them was set. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2023-04-04 7:55 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-04-02 13:28 bug#62614: Tramp attempts to remove lock file with 'remote-file-name-inhibit-locks t Yuri D'Elia 2023-04-03 8:35 ` Michael Albinus 2023-04-03 9:19 ` Yuri D'Elia 2023-04-03 9:54 ` Michael Albinus 2023-04-03 10:01 ` Yuri D'Elia 2023-04-03 10:17 ` Yuri D'Elia 2023-04-03 10:30 ` Michael Albinus 2023-04-03 14:54 ` Yuri D'Elia 2023-04-03 16:32 ` Michael Albinus 2023-04-03 16:45 ` Eli Zaretskii 2023-04-03 18:50 ` Yuri D'Elia 2023-04-04 7:55 ` Michael Albinus 2023-04-03 14:14 ` Eli Zaretskii 2023-04-03 14:10 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).