Re: Cygwin pathconf() query filesystem kernel data? Re: How does Cygwin detect MSFT NFSv3 file system? Re: Weird (path) problems with cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 ...

[Brian Inglis <Brian.Inglis@Shaw.ca>]

On 2023-08-18 07:09, Martin Wege via Cygwin wrote:
> On Fri, Aug 18, 2023 at 10:44 AM Corinna Vinschen via Cygwin
> <cygwin@cygwin.com> wrote:
>>
>> On Aug 17 20:49, Martin Wege via Cygwin wrote:
>>> On Mon, Aug 14, 2023 at 10:56 PM Corinna Vinschen via Cygwin
>>> <cygwin@cygwin.com> wrote:
>>>> and the result is the same.  Note that Cygwin supports MSFT NFSv3 but
>>>> not CITI NFSv4.1 internally.  No gurantee that Cygwin always does what
>>>> is necessary for that other NFS.
>>>
>>> 1. How does Cygwin detect whether something is a MSFT NFSv3, or not?
>>> Cygwin /bin/mount lists the CITI NFSv4.1 as 'nfs', so there *IS*
>>> something which detects that?
>>
>> The filesystem name returned by NtQueryVolumeInformationFile is "NFS".
>> If any other NFS returns the same filesystem name, it will be treated
>> just like MSFT NFSv3.
>>
>>> 2. Are Cygwin soft link handing depend on MSFT NFSv3 or not, i.e. does
>>> the Cygwin soft link code behave differently for MSFT NFSv3 file
>>> systems?
>>
>> Yes.  NFS doesn't support symlink creation and symlink reading via
>> the usual functions, because Windows symlinks are created as reparse
>> points.  NFS doesn't support reparse points.  So the developers of
>> the MSFT NFS client had to invent their own way to create and
>> read NFS symlinks:
>>
>> https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/path.cc;hb=HEAD#l1719
>>
>> https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/path.cc;hb=HEAD#l2750
>>
>>> 3. Does Cygwin implement the pathconf() api?
>>
>> Yes.  Surprisingly, you can check this yourself by just calling the
>> function and trying to compile your code.
> 
> Apologies, how do we say in German? "Ich sollte meine Frage konkretisieren:"
> 
> Does the Cygwin implementation of pathconf() support query data of the
> underlying filesystem based on data from the kernel, as UNIX does? So
> pathconf() returns different values for NTFS, ReFS, or Windows builtin
> NFSv3?
> 
> I am asking, because as far as I know the Linux implementation is not
> a syscall, and instead glibc guesses values based on builtin static
> data, and whatever fstatfs() has to offer. Compared to that UNIX
> (Solaris, AIX, HPUX, ...) have pathconf() as a syscall, and actually
> ask the filesystem itself.

Many library functions are implemented as documented either in the Cygwin 
packages cygwin-doc and man-pages-posix available for installation; and use as 
e.g. `man 3p fpathconf`, also available online at:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/fpathconf.html or
https://man7.org/linux/man-pages/man3/fpathconf.3p.html
and for comparison and reference we make Cygwin package man-pages-linux 
available for installation; and use as e.g. `man -m linux 3 fpathconf`, also 
available online at:

	https://man7.org/linux/man-pages/man3/fpathconf.3.html

suggestions for setup are in the package announcements made every 9-12 weeks 
when the latest Linux man-pages package is released and updated on Cygwin.

Please also note that the getconf(1) program is installed as part of Cygwin and 
can access f/pathconf variables associated with a pathname argument, as shown in 
getconf(1) `man 1 getconf` and getconf(1p) `man 1p getconf`.


-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry