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

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

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