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

Previous Next

Full log

View this message in rfc822 format

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Yuri D'Elia <wavexx <at> thregr.org>
Cc: 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 11:54:08 +0200

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

Previous Next

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