Well, this was only happening in my hobbyOS but I thought that it would
be of interest for you, to know what happens if lchown is not supported
by a kernel.
Anyway, some days later, I decided to include support for lchown in the
Fiwix kernel [1] and, so far, all is working finely.
Consider to close this case if you accept that chown and chgrp can
behave incorrectly on a system without support for lchown.
Thank you.
Best regards.
[1]
<https://github.com/mikaku/Fiwix/commit/4a82a2de818436a42ab22e34caa6a68b66c93b0a>
On 9/8/23 04:21, Bruno Haible wrote:
Jordi Sanfeliu wrote in
<https://lists.gnu.org/archive/html/bug-gnulib/2023-07/msg00116.html>:
I've detected that chown and chgrp commands will not change the
owner/group of a device file (char or block) that doesn't exist on a
system that don't has the system call sys_lchown.
On which platform do you see this? I'm asking because
- on most current portability targets (Linux, macOS, *BSD, AIX, Solaris,
Cygwin)
the configure test
checking whether chown dereferences symlinks...
reports 'yes', thus CHOWN_MODIFIES_SYMLINK will not be defined.
That's because lchown is part of POSIX. See
<https://pubs.opengroup.org/onlinepubs/9699919799/functions/lchown.html>
and
<https://www.gnu.org/software/gnulib/manual/html_node/lchown.html>.
- on native Windows symlinks are not handled by gnulib and coreutils
(i.e. it's treated like a platforms without symlinks), AFAIK.
Bruno
--
Jordi Sanfeliu
FIBRANET Network Services Provider
https://www.fibranet.cat
