Re: master 9d626df: Add 'nofollow' flag to set-file-modes etc.

Re: master 9d626df: Add 'nofollow' flag to set-file-modes etc.

[Michael Albinus]

eggert@cs.ucla.edu (Paul Eggert) writes:

Hi Paul,

>     Add 'nofollow' flag to set-file-modes etc.

>     * lisp/net/tramp-adb.el (tramp-adb-handle-set-file-modes):
>     * lisp/net/tramp-sh.el (tramp-sh-handle-set-file-modes):
>     * lisp/net/tramp-smb.el (tramp-smb-handle-set-file-modes):
>     * lisp/net/tramp-sudoedit.el (tramp-sudoedit-handle-set-file-modes):
>     Accept an optional FLAG arg that is currently ignored,
>     and add a FIXME comment for it.

I'm currently working on this, and I have problems. For
tramp-adb-handle-set-file-modes and tramp-smb-handle-set-file-modes we
can simply ignore the flag, because the clients ("adb shell" and
"smbclient") do not support such an option for chmod. And I don't expect
they will support it in near future.

However, for POSIX shells it is different. FreeBSD supports the "chmod
-h" argument, which implements nofollow. See
<https://www.freebsd.org/cgi/man.cgi?chmod>. I could check for this
argument, and use if possible.

But what shall I do if the target system runs GNU/Linux? chmod(1) does
not offer any comparable argument. Shall I simply ignore nofollow there?

Does anybody know, whether there are plans to extend chmod accordingly,
for example the version in coreutils? Or is there an alternative
possiblity to change the permission of the symbolic link?

Best regards, Michael.

Re: master 9d626df: Add 'nofollow' flag to set-file-modes etc.

[Paul Eggert]

On 2/24/20 5:52 AM, Michael Albinus wrote:

> However, for POSIX shells it is different. FreeBSD supports the "chmod
> -h" argument, which implements nofollow. See
> <https://www.freebsd.org/cgi/man.cgi?chmod>. I could check for this
> argument, and use if possible.
> 
> But what shall I do if the target system runs GNU/Linux? chmod(1) does
> not offer any comparable argument. Shall I simply ignore nofollow there?

How about something like this?

if (chmod -h works); then
   chmod -h MODE FILE
elif (test -h works); then
   test -h FILE && chmod MODE FILE
else
   chmod MODE FILE
fi

I'm suggesting 'test -h' rather than 'test -L' here because some ancient 
platforms support the former but not the latter.

> Does anybody know, whether there are plans to extend chmod accordingly,
> for example the version in coreutils? Or is there an alternative
> possiblity to change the permission of the symbolic link?

It should be added to the coreutils TODO list, if it's not there 
already. On GNU/Linux symlink modes cannot be changed, for what it's 
worth, so chmod -h would merely be a safety feature.

Re: master 9d626df: Add 'nofollow' flag to set-file-modes etc.

[Michael Albinus]

Paul Eggert <eggert@cs.ucla.edu> writes:

Hi Paul,

>> But what shall I do if the target system runs GNU/Linux? chmod(1)
>> does not offer any comparable argument. Shall I simply ignore
>> nofollow there?
>
> How about something like this?
>
> if (chmod -h works); then
>   chmod -h MODE FILE
> elif (test -h works); then
>   test -h FILE && chmod MODE FILE
> else
>   chmod MODE FILE
> fi

Hmm. In the Elisp manual, you have added to `set-file-modes':

--8<---------------cut here---------------start------------->8---
On platforms that do not support changing mode bits on a symbolic link,
this function signals an error when FILENAME is a symbolic link and FLAG
is ‘nofollow’.
--8<---------------cut here---------------end--------------->8---

Shouldn't Tramp behave similar, and raise an error if "chmod -h" or
something similar does not work? "Equal rights for all" :-)

Best regards, Michael.

Re: master 9d626df: Add 'nofollow' flag to set-file-modes etc.

[Paul Eggert]

On 2/25/20 1:15 AM, Michael Albinus wrote:
> Shouldn't Tramp behave similar, and raise an error if "chmod -h" or
> something similar does not work?

Yes and no. If FOO is a symlink and "chmod -h FOO" fails, set-file-modes 
should signal an error. But if FOO is a non-symlink file and "chmod -h 
FOO" fails on a platform like GNU/Linux where chmod does not have an -h 
option, set-file-modes should not signal an error; it should use plain 
"chmod FOO" instead.

(Andreas's recent comment was right as usual, by the way.)

PS. I followed up the set-file-modes change with a similar proposal for 
set-file-times (Bug#39773).

Re: master 9d626df: Add 'nofollow' flag to set-file-modes etc.

[Michael Albinus]

Paul Eggert <eggert@cs.ucla.edu> writes:

Hi Paul,

> On 2/25/20 1:15 AM, Michael Albinus wrote:
>> Shouldn't Tramp behave similar, and raise an error if "chmod -h" or
>> something similar does not work?
>
> Yes and no. If FOO is a symlink and "chmod -h FOO" fails,
> set-file-modes should signal an error. But if FOO is a non-symlink
> file and "chmod -h FOO" fails on a platform like GNU/Linux where chmod
> does not have an -h option, set-file-modes should not signal an error;
> it should use plain "chmod FOO" instead.

I see. But then there are still problems like bug#39793, which I've
reported earlier tonight. "chmod -h" would suffer from the same problem
on a remote system with mounted files, I fear.

> PS. I followed up the set-file-modes change with a similar proposal
> for set-file-times (Bug#39773).

I've seen this. Fortunately, "touch -h" is more common, so there
shouldn't be a problem for Tramp.

Best regards, Michael.

Re: master 9d626df: Add 'nofollow' flag to set-file-modes etc.

[Andreas Schwab]

On Feb 24 2020, Paul Eggert wrote:

> elif (test -h works); then
>   test -h FILE && chmod MODE FILE

ITYM: test ! -h FILE || chmod MODE FILE

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."