[PATCH] Cygwin: fchmodat: add limited support for AT_SYMLINK_NOFOLLOW

[Ken Brown]

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