GNU bug report logs - #62614
Tramp attempts to remove lock file with 'remote-file-name-inhibit-locks t

Previous Next

Package: emacs;

Reported by: Yuri D'Elia <wavexx <at> thregr.org>

Date: Sun, 2 Apr 2023 13:29:01 UTC

Severity: normal

Fixed in version 30.1

Done: Michael Albinus <michael.albinus <at> gmx.de>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: wavexx <at> thregr.org, 62614 <at> debbugs.gnu.org
Subject: bug#62614: Tramp attempts to remove lock file with 'remote-file-name-inhibit-locks t
Date: Mon, 03 Apr 2023 19:45:11 +0300
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  62614 <at> 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.




This bug report was last modified 2 years and 142 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.