* Re: master 9d626df: Add 'nofollow' flag to set-file-modes etc.
[not found] ` <20200224004619.58020206ED@vcs0.savannah.gnu.org>
@ 2020-02-24 13:52 ` Michael Albinus
2020-02-25 0:25 ` Paul Eggert
0 siblings, 1 reply; 6+ messages in thread
From: Michael Albinus @ 2020-02-24 13:52 UTC (permalink / raw)
To: emacs-devel; +Cc: Paul Eggert
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: master 9d626df: Add 'nofollow' flag to set-file-modes etc.
2020-02-24 13:52 ` master 9d626df: Add 'nofollow' flag to set-file-modes etc Michael Albinus
@ 2020-02-25 0:25 ` Paul Eggert
2020-02-25 9:15 ` Michael Albinus
2020-02-25 9:23 ` Andreas Schwab
0 siblings, 2 replies; 6+ messages in thread
From: Paul Eggert @ 2020-02-25 0:25 UTC (permalink / raw)
To: Michael Albinus; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: master 9d626df: Add 'nofollow' flag to set-file-modes etc.
2020-02-25 0:25 ` Paul Eggert
@ 2020-02-25 9:15 ` Michael Albinus
2020-02-25 23:02 ` Paul Eggert
2020-02-25 9:23 ` Andreas Schwab
1 sibling, 1 reply; 6+ messages in thread
From: Michael Albinus @ 2020-02-25 9:15 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: master 9d626df: Add 'nofollow' flag to set-file-modes etc.
2020-02-25 0:25 ` Paul Eggert
2020-02-25 9:15 ` Michael Albinus
@ 2020-02-25 9:23 ` Andreas Schwab
1 sibling, 0 replies; 6+ messages in thread
From: Andreas Schwab @ 2020-02-25 9:23 UTC (permalink / raw)
To: Paul Eggert; +Cc: Michael Albinus, emacs-devel
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."
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: master 9d626df: Add 'nofollow' flag to set-file-modes etc.
2020-02-25 9:15 ` Michael Albinus
@ 2020-02-25 23:02 ` Paul Eggert
2020-02-26 0:29 ` Michael Albinus
0 siblings, 1 reply; 6+ messages in thread
From: Paul Eggert @ 2020-02-25 23:02 UTC (permalink / raw)
To: Michael Albinus; +Cc: emacs-devel
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).
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: master 9d626df: Add 'nofollow' flag to set-file-modes etc.
2020-02-25 23:02 ` Paul Eggert
@ 2020-02-26 0:29 ` Michael Albinus
0 siblings, 0 replies; 6+ messages in thread
From: Michael Albinus @ 2020-02-26 0:29 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-02-26 0:29 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20200224004617.19362.5846@vcs0.savannah.gnu.org>
[not found] ` <20200224004619.58020206ED@vcs0.savannah.gnu.org>
2020-02-24 13:52 ` master 9d626df: Add 'nofollow' flag to set-file-modes etc Michael Albinus
2020-02-25 0:25 ` Paul Eggert
2020-02-25 9:15 ` Michael Albinus
2020-02-25 23:02 ` Paul Eggert
2020-02-26 0:29 ` Michael Albinus
2020-02-25 9:23 ` Andreas Schwab
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).