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