On 1/27/2021 8:27 AM, Corinna Vinschen via Cygwin-patches wrote:
On Jan 27 08:22, Ken Brown via Cygwin-patches wrote:
On 1/27/2021 7:40 AM, Corinna Vinschen via Cygwin-patches wrote:
On Jan 26 16:30, Ken Brown via Cygwin-patches wrote:
Allow fchmodat with the AT_SYMLINK_NOFOLLOW flag to succeed on
non-symlinks. Previously it always failed, as it does on Linux. But
POSIX permits it to succeed on non-symlinks even if it fails on
symlinks.
The reason for following POSIX rather than Linux is to make gnulib
report that fchmodat works on Cygwin. This improves the efficiency of
packages like GNU tar that use gnulib's fchmodat module. Previously
such packages would use a gnulib replacement for fchmodat on Cygwin.
Wait, what? So if Cygwin behaves like Linux, gnulib treats fchmodat
as non-working? So what does gnulib do on a Linux system? Does it
use its own fchmodat there, too?
Apparently so. Here's a comment from gnulib's test program for fchmodat:
/* Test whether fchmodat+AT_SYMLINK_NOFOLLOW works on
non-symlinks.
This test fails on GNU/Linux with glibc 2.31 (but not on
GNU/kFreeBSD nor GNU/Hurd) and Cygwin 2.9. */
I agree that it's strange.
¯\_(ツ)_/¯
I'll go ahead and submit a revised patch for the record, and you can decide
whether you want to deviate from Linux. My own opinion is that it can't be bad
to support a flag that Linux doesn't support, but I don't feel strongly about it.
BTW, the mistake in the first version of the patch is that I forgot to specify
PC_SYM_NOFOLLOW in the path_conv constructor.
Ken
