X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 735633858028
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1692046604;
	bh=ggEZjPQk8pOmGmL/WnvCmdFHHBgApRQAW2dRQx2T7AQ=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=kCJX0/AqYMjs54N1z4NU3RdEa5a/8cCaDBJBg0ke0BQJoRMokdd/s4WVegwHi35Cp
	 gST/zQRMz63KWPihbfV8D+z+TMYSjd+3aFLlujSLJKgo9jSuvFLfOzY/QhvX2BwxRR
	 CTkXhhSn+kf9t5vCdkCuT/o/xTyZDgrXAPu+lN2Y=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DD9AE3858422
Date: Mon, 14 Aug 2023 22:56:05 +0200
To: Roland Mainz <roland DOT mainz AT nrubsig DOT org>
Subject: Re: Weird (path) problems with cygwin test release
 3.5.0-0.384.g9939aa7d0945.x86_64 ...
Message-ID: <ZNqU5c5pMS2cQbsc@calimero.vinschen.de>
Mail-Followup-To: Roland Mainz <roland DOT mainz AT nrubsig DOT org>,
	cygwin AT cygwin DOT com
References: <a0f1e420-ae48-49a3-9300-c56f1948ad9b DOT 8d485f54-9f47-42b0-bdcb-9635fbf663c3 DOT 6697971f-86bc-49dc-8072-c37095eed858 AT emailsignatures365 DOT codetwo DOT com>
 <a0f1e420-ae48-49a3-9300-c56f1948ad9b DOT 93e247b8-206a-49dd-b71c-9240681180cb DOT 7748cdc6-d053-4197-9372-3b4751ae3949 AT emailsignatures365 DOT codetwo DOT com>
 <a0f1e420-ae48-49a3-9300-c56f1948ad9b DOT e52b7f5f-5a09-4346-99f8-a6591191169c DOT 10af45d3-4cfc-48f7-a293-b6d9fa78cdd1 AT emailsignatures365 DOT codetwo DOT com>
 <AM5PR0502MB30752878C878948E660A73179210A AT AM5PR0502MB3075 DOT eurprd05 DOT prod DOT outlook DOT com>
 <ZNoAR4fBMXknsn5z AT calimero DOT vinschen DOT de>
 <CAKAoaQn47pu510onZDwh4baES-bhxtuSy3SxDCv7sXw5T94pzA AT mail DOT gmail DOT com>
 <CAKAoaQnvSZDD6mitFsdD==aOi0n9h3JSAEiJo8QXCRAf58H_Sw AT mail DOT gmail DOT com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKAoaQnvSZDD6mitFsdD==aOi0n9h3JSAEiJo8QXCRAf58H_Sw@mail.gmail.com>
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>, cygwin AT cygwin DOT com
Content-Type: text/plain; charset="utf-8"
Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 37EKujHC013679

On Aug 14 19:29, Roland Mainz via Cygwin wrote:
> On Mon, Aug 14, 2023 at 6:25 PM Roland Mainz <roland DOT mainz AT nrubsig DOT org> wrote:
> > On Mon, Aug 14, 2023 at 12:21 PM Corinna Vinschen via Cygwin
> > <cygwin AT cygwin DOT 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

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple