* Weird (path) problems with cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 ... [not found] ` <a0f1e420-ae48-49a3-9300-c56f1948ad9b.e52b7f5f-5a09-4346-99f8-a6591191169c.10af45d3-4cfc-48f7-a293-b6d9fa78cdd1@emailsignatures365.codetwo.com> @ 2023-08-11 13:36 ` Mainz, Roland 2023-08-14 10:21 ` Corinna Vinschen 0 siblings, 1 reply; 14+ messages in thread From: Mainz, Roland @ 2023-08-11 13:36 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Weird (path) problems with cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 ... 2023-08-11 13:36 ` Weird (path) problems with cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 Mainz, Roland @ 2023-08-14 10:21 ` Corinna Vinschen 2023-08-14 16:25 ` Roland Mainz 0 siblings, 1 reply; 14+ messages in thread From: Corinna Vinschen @ 2023-08-14 10:21 UTC (permalink / raw) To: Mainz, Roland; +Cc: cygwin 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Weird (path) problems with cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 ... 2023-08-14 10:21 ` Corinna Vinschen @ 2023-08-14 16:25 ` Roland Mainz 2023-08-14 17:29 ` Roland Mainz 0 siblings, 1 reply; 14+ messages in thread From: Roland Mainz @ 2023-08-14 16:25 UTC (permalink / raw) To: cygwin 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;) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Weird (path) problems with cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 ... 2023-08-14 16:25 ` Roland Mainz @ 2023-08-14 17:29 ` Roland Mainz 2023-08-14 19:42 ` Martin Wege 2023-08-14 20:56 ` Corinna Vinschen 0 siblings, 2 replies; 14+ messages in thread From: Roland Mainz @ 2023-08-14 17:29 UTC (permalink / raw) To: cygwin 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;) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Weird (path) problems with cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 ... 2023-08-14 17:29 ` Roland Mainz @ 2023-08-14 19:42 ` Martin Wege 2023-08-14 20:57 ` Corinna Vinschen 2023-08-14 20:56 ` Corinna Vinschen 1 sibling, 1 reply; 14+ messages in thread From: Martin Wege @ 2023-08-14 19:42 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Weird (path) problems with cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 ... 2023-08-14 19:42 ` Martin Wege @ 2023-08-14 20:57 ` Corinna Vinschen 0 siblings, 0 replies; 14+ messages in thread From: Corinna Vinschen @ 2023-08-14 20:57 UTC (permalink / raw) To: Martin Wege; +Cc: cygwin 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Weird (path) problems with cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 ... 2023-08-14 17:29 ` Roland Mainz 2023-08-14 19:42 ` Martin Wege @ 2023-08-14 20:56 ` Corinna Vinschen 2023-08-17 18:49 ` How does Cygwin detect MSFT NFSv3 file system? " Martin Wege 1 sibling, 1 reply; 14+ messages in thread From: Corinna Vinschen @ 2023-08-14 20:56 UTC (permalink / raw) To: Roland Mainz; +Cc: cygwin 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* How does Cygwin detect MSFT NFSv3 file system? Re: Weird (path) problems with cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 ... 2023-08-14 20:56 ` Corinna Vinschen @ 2023-08-17 18:49 ` Martin Wege 2023-08-18 8:44 ` Corinna Vinschen 0 siblings, 1 reply; 14+ messages in thread From: Martin Wege @ 2023-08-17 18:49 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* 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 ... 2023-08-17 18:49 ` How does Cygwin detect MSFT NFSv3 file system? " Martin Wege @ 2023-08-18 8:44 ` Corinna Vinschen 2023-08-18 13:09 ` Cygwin pathconf() query filesystem kernel data? " Martin Wege 0 siblings, 1 reply; 14+ messages in thread From: Corinna Vinschen @ 2023-08-18 8:44 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* 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 ... 2023-08-18 8:44 ` Corinna Vinschen @ 2023-08-18 13:09 ` Martin Wege 2023-08-19 17:50 ` Brian Inglis 0 siblings, 1 reply; 14+ messages in thread From: Martin Wege @ 2023-08-18 13:09 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* 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 ... 2023-08-18 13:09 ` Cygwin pathconf() query filesystem kernel data? " Martin Wege @ 2023-08-19 17:50 ` Brian Inglis 2023-08-21 12:03 ` Martin Wege 0 siblings, 1 reply; 14+ messages in thread From: Brian Inglis @ 2023-08-19 17:50 UTC (permalink / raw) To: cygwin; +Cc: Martin Wege 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* 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 ... 2023-08-19 17:50 ` Brian Inglis @ 2023-08-21 12:03 ` Martin Wege 2023-08-21 22:07 ` Brian Inglis 0 siblings, 1 reply; 14+ messages in thread From: Martin Wege @ 2023-08-21 12:03 UTC (permalink / raw) To: cygwin, Corinna Vinschen 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* 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 ... 2023-08-21 12:03 ` Martin Wege @ 2023-08-21 22:07 ` Brian Inglis 2023-08-24 16:27 ` Martin Wege 0 siblings, 1 reply; 14+ messages in thread From: Brian Inglis @ 2023-08-21 22:07 UTC (permalink / raw) To: cygwin; +Cc: Martin Wege 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* 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 ... 2023-08-21 22:07 ` Brian Inglis @ 2023-08-24 16:27 ` Martin Wege 0 siblings, 0 replies; 14+ messages in thread From: Martin Wege @ 2023-08-24 16:27 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2023-08-24 16:27 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <a0f1e420-ae48-49a3-9300-c56f1948ad9b.8d485f54-9f47-42b0-bdcb-9635fbf663c3.6697971f-86bc-49dc-8072-c37095eed858@emailsignatures365.codetwo.com> [not found] ` <a0f1e420-ae48-49a3-9300-c56f1948ad9b.93e247b8-206a-49dd-b71c-9240681180cb.7748cdc6-d053-4197-9372-3b4751ae3949@emailsignatures365.codetwo.com> [not found] ` <a0f1e420-ae48-49a3-9300-c56f1948ad9b.e52b7f5f-5a09-4346-99f8-a6591191169c.10af45d3-4cfc-48f7-a293-b6d9fa78cdd1@emailsignatures365.codetwo.com> 2023-08-11 13:36 ` Weird (path) problems with cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 Mainz, Roland 2023-08-14 10:21 ` Corinna Vinschen 2023-08-14 16:25 ` Roland Mainz 2023-08-14 17:29 ` Roland Mainz 2023-08-14 19:42 ` Martin Wege 2023-08-14 20:57 ` Corinna Vinschen 2023-08-14 20:56 ` Corinna Vinschen 2023-08-17 18:49 ` How does Cygwin detect MSFT NFSv3 file system? " Martin Wege 2023-08-18 8:44 ` Corinna Vinschen 2023-08-18 13:09 ` Cygwin pathconf() query filesystem kernel data? " Martin Wege 2023-08-19 17:50 ` Brian Inglis 2023-08-21 12:03 ` Martin Wege 2023-08-21 22:07 ` Brian Inglis 2023-08-24 16:27 ` Martin Wege
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).