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 ...

[Martin Wege <martin.l.wege@gmail.com>]

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.

Thanks,
Martin