Weird (path) problems with cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 ...

Weird (path) problems with cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 ...

[Mainz, Roland]

Hi!

----

Cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 has some weird path problems with network filesystems on Windows 10. Previous stable version of Cygwin (4.7.x ?) worked fine.

In our case we have a project with both custom binaries and sources both hosted on the filesystem as /home/rmainz/ (i.e. filesystem mounted on H:, and then bind mount to /home/rmainz).

After updating Cygwin to 3.5.0-0.384.g9939aa7d0945.x86_64 the build now fails *IF* I access the binaries with their full absolute path AND the sources with their absolute path:
---- snip ----
$ cd /home/rmainz/tmp/try10_rde_new_rds/RDE-Development/build_windows4/tmp
$ ls -l x.cpp
-rw-r--r-- 1 rmainz rovdevel 110 Aug 11 15:32 x.cpp
$ /home/rmainz/tmp/try10_rde_new_rds/Dependencies/win/qt/qt_5_15_2/Tools/mingw810_64/bin/c++ $PWD/x.cpp
c++.exe: error: /home/rmainz/tmp/try10_rde_new_rds/RDE-Development/build_windows4/tmp/x.cpp: No such file or directory
c++.exe: fatal error: no input files
compilation terminated.
---- snip ----

Even more weird is that if I try to debug this via strace I get this:
---- snip ----
$ strace -o mylog.log /home/rmainz/tmp/try10_rde_new_rds/Dependencies/win/qt/qt_5_15_2/Tools/mingw810_64/bin/c++ $PWD/x.cpp
strace.exe: error creating process C:\cygwin64\home\rmainz\tmp\try10_rde_new_rds\Dependencies\win\qt\qt_5_15_2\Tools\mingw810_64\bin\c++, (error 2)
---- snip ----

Note that the Windows-style path doesn't start with H:\tmp as I would expect - it starts with C:\cygwin64\, followed by the bind mount name (\home\rmainz).

----

Bye,
Roland

i. A. Roland Mainz
Entwickler Steuerungssoftware
TEE

ROVEMA GmbH

Industriestr. 1, 35463
Fernwald, Germany
 T  +49 641 409 528
 @ Roland.Mainz@rovema.de
 
www.rovema.com


Rovema
It's about your products.
https://www.rovema-experience.com/


ROVEMA GmbH
Industriestrasse 1, 35463 Fernwald, Germany
Geschäftsführer:
Christoph Gusenleitner
Dr. Dirk Panhans
Handelsregister-Eintrag/Commercial Register: Amtsgericht Gießen, HRB 8551
USt.-Ident./VAT ID No.: DE 301 430 123

Re: Weird (path) problems with cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 ...

[Corinna Vinschen]

On Aug 11 13:36, Mainz, Roland via Cygwin wrote:
> Hi!
> 
> ----
> 
> Cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 has some weird
> path problems with network filesystems on Windows 10. Previous stable
> version of Cygwin (4.7.x ?) worked fine.

3.4.7

> In our case we have a project with both custom binaries and sources
> both hosted on the filesystem as /home/rmainz/ (i.e. filesystem
> mounted on H:, and then bind mount to /home/rmainz).
> 
> After updating Cygwin to 3.5.0-0.384.g9939aa7d0945.x86_64 the build
> now fails *IF* I access the binaries with their full absolute path AND
> the sources with their absolute path:
> ---- snip ----
> $ cd /home/rmainz/tmp/try10_rde_new_rds/RDE-Development/build_windows4/tmp
> $ ls -l x.cpp
> -rw-r--r-- 1 rmainz rovdevel 110 Aug 11 15:32 x.cpp
> $ /home/rmainz/tmp/try10_rde_new_rds/Dependencies/win/qt/qt_5_15_2/Tools/mingw810_64/bin/c++ $PWD/x.cpp
> c++.exe: error: /home/rmainz/tmp/try10_rde_new_rds/RDE-Development/build_windows4/tmp/x.cpp: No such file or directory
> c++.exe: fatal error: no input files
> compilation terminated.
> ---- snip ----

I can't reproduce this:

$ net use H: <blah>
$ mount -o exec H: /home/rmainz
$ cd /home/rmainz/tmp
$ cp /bin/cat.exe .
$ mkdir baz
$ echo foo > baz/bar
$ /home/rmainz/tmp/cat $PWD/baz/bar
foo

> Even more weird is that if I try to debug this via strace I get this:
> ---- snip ----
> $ strace -o mylog.log /home/rmainz/tmp/try10_rde_new_rds/Dependencies/win/qt/qt_5_15_2/Tools/mingw810_64/bin/c++ $PWD/x.cpp
> strace.exe: error creating process C:\cygwin64\home\rmainz\tmp\try10_rde_new_rds\Dependencies\win\qt\qt_5_15_2\Tools\mingw810_64\bin\c++, (error 2)
> ---- snip ----
> 
> Note that the Windows-style path doesn't start with H:\tmp as I would
> expect - it starts with C:\cygwin64\, followed by the bind mount name
> (\home\rmainz).

Looks like your mount point is only temporary, i. e., you created it
with mount at runtime in your shell (as I did above).  If you add it to
your fstab file, e. g., /etc/fstab.d/rmainz, it will be persistent.

The problem here is this: To allow debugging bugs in Cygwin itself,
strace is a MingW executable.  As a non-Cygwin executable, it does not
have access to the Cygwin-specific shared memory region containing
mount points.

Thus, it reads the mount points from the /etc/fstab and
/etc/fstab.d/$USER files.  If the mount point is missing in these files,
strace can't use it.


Corinna

Re: Weird (path) problems with cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 ...

[Roland Mainz]

On Mon, Aug 14, 2023 at 12:21 PM Corinna Vinschen via Cygwin
<cygwin@cygwin.com> wrote:
>
> On Aug 11 13:36, Mainz, Roland via Cygwin wrote:
> > Hi!
> >
> > ----
> >
> > Cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 has some weird
> > path problems with network filesystems on Windows 10. Previous stable
> > version of Cygwin (4.7.x ?) worked fine.
>
> 3.4.7

Autsch. My mistake... ;-/

> > In our case we have a project with both custom binaries and sources
> > both hosted on the filesystem as /home/rmainz/ (i.e. filesystem
> > mounted on H:, and then bind mount to /home/rmainz).
> >
> > After updating Cygwin to 3.5.0-0.384.g9939aa7d0945.x86_64 the build
> > now fails *IF* I access the binaries with their full absolute path AND
> > the sources with their absolute path:
> > ---- snip ----
> > $ cd /home/rmainz/tmp/try10_rde_new_rds/RDE-Development/build_windows4/tmp
> > $ ls -l x.cpp
> > -rw-r--r-- 1 rmainz rovdevel 110 Aug 11 15:32 x.cpp
> > $ /home/rmainz/tmp/try10_rde_new_rds/Dependencies/win/qt/qt_5_15_2/Tools/mingw810_64/bin/c++ $PWD/x.cpp
> > c++.exe: error: /home/rmainz/tmp/try10_rde_new_rds/RDE-Development/build_windows4/tmp/x.cpp: No such file or directory
> > c++.exe: fatal error: no input files
> > compilation terminated.
> > ---- snip ----
>
> I can't reproduce this:
>
> $ net use H: <blah>

Is <blah> Samba, CIFS or NFS ?

> $ mount -o exec H: /home/rmainz
> $ cd /home/rmainz/tmp
> $ cp /bin/cat.exe .
> $ mkdir baz
> $ echo foo > baz/bar
> $ /home/rmainz/tmp/cat $PWD/baz/bar
> foo

Grumpf... ;-(

... I'm still seeing this problem.
The sources we are building are proprietary (sorry), but I can
reproduce this with both CITI's NFSv4.1 and Windows 10 builtin NFSv3
clients.

Setup for Windows's NFSv3 client on Cygwin is simple:
1. Install Windows 10 builtin NFSv3 client via "Programs&Features" (I
think there is a way to do that in a scripted way, but I still didn't
had time to figure that out)

2. Export NFSv3 directory 10.49.20.131:/export/home/rmainz (rmainz has
uid=1616, gid=1616) on a Linux NFS-Server (RHEL, Debian etc.)

3. Mount NFSv3 filesystem in Windows 10 in a Cygwin terminal, with
default user uid=1616, gid=1616 like this:
---- snip ----
$ regtool -i -s set
'/HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/ClientForNFS/CurrentVersion/Default/AnonymousUID'
1616
$ regtool -i -s set
'/HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/ClientForNFS/CurrentVersion/Default/AnonymousGID'
1616
$ /cygdrive/c/Windows/system32/mount -o anon
'\\10.49.20.131\export\home\rmainz' H:
---- snip ----

4. After that I started building our sources with Cygwin 3.4.7
(works), then closed all Cygwin windows etc., and installed Cygwin
3.5.0-0.388.g1a646ad7970a.x86_64 (reboot or not reboot - doesn't
matter). After that the build fails.

- See https://rovema.kpaste.net/e5774d8077 build log on Cygwin 3.4.7,
which works without problems
- See https://rovema.kpaste.net/1a3b98e0b for the build failure on
Cygwin 3.5.0-0.388.g1a646ad7970a.x86_64
- The horrifying abdomination ("buildrdecygwin.bash") used to build
the mess can be found at https://rovema.kpaste.net/e98be

----

Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

Re: Weird (path) problems with cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 ...

[Roland Mainz]

On Mon, Aug 14, 2023 at 6:25 PM Roland Mainz <roland.mainz@nrubsig.org> wrote:
> On Mon, Aug 14, 2023 at 12:21 PM Corinna Vinschen via Cygwin
> <cygwin@cygwin.com> wrote:
> > On Aug 11 13:36, Mainz, Roland via Cygwin wrote:
[snip]
> > > In our case we have a project with both custom binaries and sources
> > > both hosted on the filesystem as /home/rmainz/ (i.e. filesystem
> > > mounted on H:, and then bind mount to /home/rmainz).
> > >
> > > After updating Cygwin to 3.5.0-0.384.g9939aa7d0945.x86_64 the build
> > > now fails *IF* I access the binaries with their full absolute path AND
> > > the sources with their absolute path:
> > > ---- snip ----
> > > $ cd /home/rmainz/tmp/try10_rde_new_rds/RDE-Development/build_windows4/tmp
> > > $ ls -l x.cpp
> > > -rw-r--r-- 1 rmainz rovdevel 110 Aug 11 15:32 x.cpp
> > > $ /home/rmainz/tmp/try10_rde_new_rds/Dependencies/win/qt/qt_5_15_2/Tools/mingw810_64/bin/c++ $PWD/x.cpp
> > > c++.exe: error: /home/rmainz/tmp/try10_rde_new_rds/RDE-Development/build_windows4/tmp/x.cpp: No such file or directory
> > > c++.exe: fatal error: no input files
> > > compilation terminated.
> > > ---- snip ----
> >
> > I can't reproduce this:
> >
> > $ net use H: <blah>
>
> Is <blah> Samba, CIFS or NFS ?
>
> > $ mount -o exec H: /home/rmainz
> > $ cd /home/rmainz/tmp
> > $ cp /bin/cat.exe .
> > $ mkdir baz
> > $ echo foo > baz/bar
> > $ /home/rmainz/tmp/cat $PWD/baz/bar
> > foo
>
> Grumpf... ;-(
>
> ... I'm still seeing this problem.
> The sources we are building are proprietary (sorry), but I can
> reproduce this with both CITI's NFSv4.1 and Windows 10 builtin NFSv3
> clients.
>
> Setup for Windows's NFSv3 client on Cygwin is simple:
> 1. Install Windows 10 builtin NFSv3 client via "Programs&Features" (I
> think there is a way to do that in a scripted way, but I still didn't
> had time to figure that out)
>
> 2. Export NFSv3 directory 10.49.20.131:/export/home/rmainz (rmainz has
> uid=1616, gid=1616) on a Linux NFS-Server (RHEL, Debian etc.)
>
> 3. Mount NFSv3 filesystem in Windows 10 in a Cygwin terminal, with
> default user uid=1616, gid=1616 like this:
> ---- snip ----
> $ regtool -i -s set
> '/HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/ClientForNFS/CurrentVersion/Default/AnonymousUID'
> 1616
> $ regtool -i -s set
> '/HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/ClientForNFS/CurrentVersion/Default/AnonymousGID'
> 1616
> $ /cygdrive/c/Windows/system32/mount -o anon
> '\\10.49.20.131\export\home\rmainz' H:
> ---- snip ----
>
> 4. After that I started building our sources with Cygwin 3.4.7
> (works), then closed all Cygwin windows etc., and installed Cygwin
> 3.5.0-0.388.g1a646ad7970a.x86_64 (reboot or not reboot - doesn't
> matter). After that the build fails.
>
> - See https://rovema.kpaste.net/e5774d8077 build log on Cygwin 3.4.7,
> which works without problems
> - See https://rovema.kpaste.net/1a3b98e0b for the build failure on
> Cygwin 3.5.0-0.388.g1a646ad7970a.x86_64
> - The horrifying abdomination ("buildrdecygwin.bash") used to build
> the mess can be found at https://rovema.kpaste.net/e98be

It seems the issue can be reduced to this on  Cygwin
3.5.0-0.388.g1a646ad7970a.x86_64 - c++ with H:/path/.../x.cpp works,
c++ with  /home/rmainz/path/.../x.cpp does not.

This definitely *WORKED* in Cygwin 3.4.7:

Example:
---- snip ----
$ uname -a
CYGWIN_NT-10.0-19045 WINGRENDEL01 3.5.0-0.388.g1a646ad7970a.x86_64
2023-08-11 14:14 UTC x86_64 Cygwin

$ cat /etc/fstab
# /etc/fstab
#
#    This file is read once by the first process in a Cygwin process tree.
#    To pick up changes, restart all Cygwin processes.  For a description
#    see https://cygwin.com/cygwin-ug-net/using.html#mount-table

# This is default anyway:
none /cygdrive cygdrive binary,posix=0,user 0 0
H:      /home/rmainz    none    binary,posix=0,user     0       0


$ mount -a

$ /home/rmainz/tmp/winnfstest/hummingbirdnfstest1/try10_rde_new_rds/Dependencies/win/qt/qt_5_15_2/Tools/mingw810_64/bin/c++
/home/rmainz/tmp/winnfstest/hummingbirdnfstest1/try10_rde_new_rds/RDE-Development/build_windows5/tmp/x.cpp
c++.exe: error:
/home/rmainz/tmp/winnfstest/hummingbirdnfstest1/try10_rde_new_rds/RDE-Development/build_windows5/tmp/x.cpp:
No such file or directory
c++.exe: fatal error: no input files
compilation terminated.

$ /home/rmainz/tmp/winnfstest/hummingbirdnfstest1/try10_rde_new_rds/Dependencies/win/qt/qt_5_15_2/Tools/mingw810_64/bin/c++
H:/tmp/winnfstest/hummingbirdnfstest1/try10_rde_new_rds/RDE-Development/build_windows5/tmp/x.cpp

$ ./a
Hello World!
---- snip ----

/proc/cygwin/h/path/... does not work either...

Does anyone have any idea what changed between Cygwin 3.4.7 and Cygwin
3.5.0-0.388.g1a646ad7970a.x86_64 in this case ?

----

Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

Re: Weird (path) problems with cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 ...

[Martin Wege]

On Mon, Aug 14, 2023 at 7:30 PM Roland Mainz via Cygwin
<cygwin@cygwin.com> wrote:
>
> On Mon, Aug 14, 2023 at 6:25 PM Roland Mainz <roland.mainz@nrubsig.org> wrote:
> > On Mon, Aug 14, 2023 at 12:21 PM Corinna Vinschen via Cygwin
> > <cygwin@cygwin.com> wrote:
> > > On Aug 11 13:36, Mainz, Roland via Cygwin wrote:
> [snip]
> > > > In our case we have a project with both custom binaries and sources
> > > > both hosted on the filesystem as /home/rmainz/ (i.e. filesystem
> > > > mounted on H:, and then bind mount to /home/rmainz).
> > > >
> > > > After updating Cygwin to 3.5.0-0.384.g9939aa7d0945.x86_64 the build
> > > > now fails *IF* I access the binaries with their full absolute path AND
> > > > the sources with their absolute path:
> > > > ---- snip ----
> > > > $ cd /home/rmainz/tmp/try10_rde_new_rds/RDE-Development/build_windows4/tmp
> > > > $ ls -l x.cpp
> > > > -rw-r--r-- 1 rmainz rovdevel 110 Aug 11 15:32 x.cpp
> > > > $ /home/rmainz/tmp/try10_rde_new_rds/Dependencies/win/qt/qt_5_15_2/Tools/mingw810_64/bin/c++ $PWD/x.cpp
> > > > c++.exe: error: /home/rmainz/tmp/try10_rde_new_rds/RDE-Development/build_windows4/tmp/x.cpp: No such file or directory
> > > > c++.exe: fatal error: no input files
> > > > compilation terminated.
> > > > ---- snip ----
> > >
> > > I can't reproduce this:
> > >
> > > $ net use H: <blah>
> >
> > Is <blah> Samba, CIFS or NFS ?
> >
> > > $ mount -o exec H: /home/rmainz
> > > $ cd /home/rmainz/tmp
> > > $ cp /bin/cat.exe .
> > > $ mkdir baz
> > > $ echo foo > baz/bar
> > > $ /home/rmainz/tmp/cat $PWD/baz/bar
> > > foo
> >
> > Grumpf... ;-(
> >
> > ... I'm still seeing this problem.
> > The sources we are building are proprietary (sorry), but I can
> > reproduce this with both CITI's NFSv4.1 and Windows 10 builtin NFSv3
> > clients.
> >
> > Setup for Windows's NFSv3 client on Cygwin is simple:
> > 1. Install Windows 10 builtin NFSv3 client via "Programs&Features" (I
> > think there is a way to do that in a scripted way, but I still didn't
> > had time to figure that out)
> >
> > 2. Export NFSv3 directory 10.49.20.131:/export/home/rmainz (rmainz has
> > uid=1616, gid=1616) on a Linux NFS-Server (RHEL, Debian etc.)
> >
> > 3. Mount NFSv3 filesystem in Windows 10 in a Cygwin terminal, with
> > default user uid=1616, gid=1616 like this:
> > ---- snip ----
> > $ regtool -i -s set
> > '/HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/ClientForNFS/CurrentVersion/Default/AnonymousUID'
> > 1616
> > $ regtool -i -s set
> > '/HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/ClientForNFS/CurrentVersion/Default/AnonymousGID'
> > 1616
> > $ /cygdrive/c/Windows/system32/mount -o anon
> > '\\10.49.20.131\export\home\rmainz' H:
> > ---- snip ----
> >
> > 4. After that I started building our sources with Cygwin 3.4.7
> > (works), then closed all Cygwin windows etc., and installed Cygwin
> > 3.5.0-0.388.g1a646ad7970a.x86_64 (reboot or not reboot - doesn't
> > matter). After that the build fails.
> >
> > - See https://rovema.kpaste.net/e5774d8077 build log on Cygwin 3.4.7,
> > which works without problems
> > - See https://rovema.kpaste.net/1a3b98e0b for the build failure on
> > Cygwin 3.5.0-0.388.g1a646ad7970a.x86_64
> > - The horrifying abdomination ("buildrdecygwin.bash") used to build
> > the mess can be found at https://rovema.kpaste.net/e98be
>
> It seems the issue can be reduced to this on  Cygwin
> 3.5.0-0.388.g1a646ad7970a.x86_64 - c++ with H:/path/.../x.cpp works,
> c++ with  /home/rmainz/path/.../x.cpp does not.
>
> This definitely *WORKED* in Cygwin 3.4.7:
>
> Example:
> ---- snip ----
> $ uname -a
> CYGWIN_NT-10.0-19045 WINGRENDEL01 3.5.0-0.388.g1a646ad7970a.x86_64
> 2023-08-11 14:14 UTC x86_64 Cygwin
>
> $ cat /etc/fstab
> # /etc/fstab
> #
> #    This file is read once by the first process in a Cygwin process tree.
> #    To pick up changes, restart all Cygwin processes.  For a description
> #    see https://cygwin.com/cygwin-ug-net/using.html#mount-table
>
> # This is default anyway:
> none /cygdrive cygdrive binary,posix=0,user 0 0
> H:      /home/rmainz    none    binary,posix=0,user     0       0
>
>
> $ mount -a
>
> $ /home/rmainz/tmp/winnfstest/hummingbirdnfstest1/try10_rde_new_rds/Dependencies/win/qt/qt_5_15_2/Tools/mingw810_64/bin/c++
> /home/rmainz/tmp/winnfstest/hummingbirdnfstest1/try10_rde_new_rds/RDE-Development/build_windows5/tmp/x.cpp
> c++.exe: error:
> /home/rmainz/tmp/winnfstest/hummingbirdnfstest1/try10_rde_new_rds/RDE-Development/build_windows5/tmp/x.cpp:
> No such file or directory
> c++.exe: fatal error: no input files
> compilation terminated.
>
> $ /home/rmainz/tmp/winnfstest/hummingbirdnfstest1/try10_rde_new_rds/Dependencies/win/qt/qt_5_15_2/Tools/mingw810_64/bin/c++
> H:/tmp/winnfstest/hummingbirdnfstest1/try10_rde_new_rds/RDE-Development/build_windows5/tmp/x.cpp
>
> $ ./a
> Hello World!
> ---- snip ----
>
> /proc/cygwin/h/path/... does not work either...
>
> Does anyone have any idea what changed between Cygwin 3.4.7 and Cygwin
> 3.5.0-0.388.g1a646ad7970a.x86_64 in this case ?
>

Maybe MinGW compat is broken in 3.5.0-0.388.g1a646ad7970a?

Thanks,
Martin

Re: Weird (path) problems with cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 ...

[Corinna Vinschen]

On Aug 14 21:42, Martin Wege via Cygwin wrote:
> Maybe MinGW compat is broken in 3.5.0-0.388.g1a646ad7970a?

There's no Mingw compatibility stuff in Cygwin.  Mingw are just
non-Cygwin binaries, just like any other native Windows tool.


Corinna

Re: Weird (path) problems with cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 ...

[Corinna Vinschen]

On Aug 14 19:29, Roland Mainz via Cygwin wrote:
> On Mon, Aug 14, 2023 at 6:25 PM Roland Mainz <roland.mainz@nrubsig.org> wrote:
> > On Mon, Aug 14, 2023 at 12:21 PM Corinna Vinschen via Cygwin
> > <cygwin@cygwin.com> wrote:
> > > On Aug 11 13:36, Mainz, Roland via Cygwin wrote:
> [snip]
> > > > In our case we have a project with both custom binaries and sources
> > > > both hosted on the filesystem as /home/rmainz/ (i.e. filesystem
> > > > mounted on H:, and then bind mount to /home/rmainz).
> > > >
> > > > After updating Cygwin to 3.5.0-0.384.g9939aa7d0945.x86_64 the build
> > > > now fails *IF* I access the binaries with their full absolute path AND
> > > > the sources with their absolute path:
> > > > ---- snip ----
> > > > $ cd /home/rmainz/tmp/try10_rde_new_rds/RDE-Development/build_windows4/tmp
> > > > $ ls -l x.cpp
> > > > -rw-r--r-- 1 rmainz rovdevel 110 Aug 11 15:32 x.cpp
> > > > $ /home/rmainz/tmp/try10_rde_new_rds/Dependencies/win/qt/qt_5_15_2/Tools/mingw810_64/bin/c++ $PWD/x.cpp
> > > > c++.exe: error: /home/rmainz/tmp/try10_rde_new_rds/RDE-Development/build_windows4/tmp/x.cpp: No such file or directory
> > > > c++.exe: fatal error: no input files
> > > > compilation terminated.
> > > > ---- snip ----
> > >
> > > I can't reproduce this:
> > >
> > > $ net use H: <blah>
> >
> > Is <blah> Samba, CIFS or NFS ?

Samba.

> > > $ mount -o exec H: /home/rmainz
> > > $ cd /home/rmainz/tmp
> > > $ cp /bin/cat.exe .
> > > $ mkdir baz
> > > $ echo foo > baz/bar
> > > $ /home/rmainz/tmp/cat $PWD/baz/bar
> > > foo
> >
> > Grumpf... ;-(
> >
> > ... I'm still seeing this problem.
> > The sources we are building are proprietary (sorry), but I can
> > reproduce this with both CITI's NFSv4.1 and Windows 10 builtin NFSv3
> > clients.

I switched the share to MSFT NFSv3

  $ mount | grep H:
  H: on /home/rmainz type nfs (binary,exec,user)

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.

> It seems the issue can be reduced to this on  Cygwin
> 3.5.0-0.388.g1a646ad7970a.x86_64 - c++ with H:/path/.../x.cpp works,
> c++ with  /home/rmainz/path/.../x.cpp does not.

Is that c++ a Cygwin binary or a native binary?  For kicks I wrote
a q&d cat as mingw executable and retried the test.  It happened
exactly what I expect to happen:

  $ /home/rmainz/tmp/cat $PWD/baz/bar
  Can't open /home/rmainz/tmp/baz/bar

Obviously, the native binary has no idea about the Cygwin mount points.
I tried this under 3.4.7 and the latest 3.5.0 with the same result.
If this c++ is a native binary, I wonder how it ever is supposed to work
with Cygwin mount points.

I also created the subdirs you're using under the assumption it has to do
with longer pathnames.  I.e. I created
/home/rmainz/tmp/winnfstest/hummingbirdnfstest1/try10_rde_new_rds/Dependencies/win/qt/qt_5_15_2/Tools/mingw810_64/bin/
and moved cat.exe there, and I created
/home/rmainz/tmp/winnfstest/hummingbirdnfstest1/try10_rde_new_rds/RDE-Development/build_windows5/tmp/
and moved my bar file in there.  Then I called

  $ /home/rmainz/tmp/winnfstest/hummingbirdnfstest1/try10_rde_new_rds/Dependencies/win/qt/qt_5_15_2/Tools/mingw810_64/bin/cat /home/rmainz/tmp/winnfstest/hummingbirdnfstest1/try10_rde_new_rds/RDE-Development/build_windows5/tmp/bar

With the mingw cat I get the output

  Can't open /home/rmainz/tmp/winnfstest/hummingbirdnfstest1/try10_rde_new_rds/RDE-Development/build_windows5/tmp/bar

With Cygwin's cat I get the output

  foo

I get the same result, independently of using 3.4.7 or 3.5.0-0.388.

Whatever happens there, it has something to do with either the c++
binary, or with something *in* the longer path which is weird.  I can't
judge that from here.


Corinna

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]

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?
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?
3. Does Cygwin implement the pathconf() api?

Thanks,
Martin

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

[Corinna Vinschen]

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.


Corinna

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]

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

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]

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

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

[Martin Wege]

On Sat, Aug 19, 2023 at 7:50 PM Brian Inglis <Brian.Inglis@shaw.ca> wrote:
>
> 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`.

Thanks, but my question was about the Cygwin *implementation*: Does it
distinguish between NTFS, REFS, FAT, NFS? Does it use data obtained
from the Windows kernel at runtime, or does it rely on static data
compiled into the cygwin.dll library?

Thanks,
Martin

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]

On 2023-08-21 06:03, Martin Wege via Cygwin wrote:
> On Sat, Aug 19, 2023 at 7:50 PM Brian Inglis <Brian.Inglis@shaw.ca> wrote:
>>
>> 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`.
> 
> Thanks, but my question was about the Cygwin *implementation*: Does it
> distinguish between NTFS, REFS, FAT, NFS? Does it use data obtained
> from the Windows kernel at runtime, or does it rely on static data
> compiled into the cygwin.dll library?

My suggestion was to encourage you to try out the command on the relevant 
filesystems, or feel free to check out the repo and the implementation.

You can search the mailing lists on inbox.sourceware.org/cygwin or mail-archive.

Volunteers focus on fixes to reproducible problems, adding function, upgrading 
packages, and quick answers to questions: the rest is up to you!

If you need professional support, try job forums to hire someone with the 
knowledge or skills to answer your questions.

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

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

[Martin Wege]

On Tue, Aug 22, 2023 at 12:07 AM Brian Inglis <Brian.Inglis@shaw.ca> wrote:
>
> On 2023-08-21 06:03, Martin Wege via Cygwin wrote:
> > On Sat, Aug 19, 2023 at 7:50 PM Brian Inglis <Brian.Inglis@shaw.ca> wrote:
> >>
> >> 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`.
> >
> > Thanks, but my question was about the Cygwin *implementation*: Does it
> > distinguish between NTFS, REFS, FAT, NFS? Does it use data obtained
> > from the Windows kernel at runtime, or does it rely on static data
> > compiled into the cygwin.dll library?
>
> My suggestion was to encourage you to try out the command on the relevant
> filesystems, or feel free to check out the repo and the implementation.

Where in the git is the implementation of pathconf()?

Thanks,
Martin