From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2155) id DD9AE3858422; Mon, 14 Aug 2023 20:56:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DD9AE3858422 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1692046567; bh=0dBt12Hb+DRwncJTO+IBjQYJk8OOFDe/VlsONQx51DA=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=NAUdhL2TqsUJgr9KSS6mXMFru5GGfJ69dGOP6dJmsic6mAO22k1TkpkL7Hby6espl 9n9WiQ0FySC1BD/GfKBzRcp37g9z+rISFYsLe0542vHyQm++W2YPcePGyjqSWfHDis F5L7bGeu/aS0DxK5I0/XKgkpgQ7AC2Iim2Cye3tk= Received: by calimero.vinschen.de (Postfix, from userid 500) id 04B4BA80CDB; Mon, 14 Aug 2023 22:56:06 +0200 (CEST) Date: Mon, 14 Aug 2023 22:56:05 +0200 From: Corinna Vinschen To: Roland Mainz Cc: cygwin@cygwin.com Subject: Re: Weird (path) problems with cygwin test release 3.5.0-0.384.g9939aa7d0945.x86_64 ... Message-ID: Reply-To: cygwin@cygwin.com Mail-Followup-To: Roland Mainz , cygwin@cygwin.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: On Aug 14 19:29, Roland Mainz via Cygwin wrote: > On Mon, Aug 14, 2023 at 6:25 PM Roland Mainz wrote: > > On Mon, Aug 14, 2023 at 12:21 PM Corinna Vinschen via Cygwin > > 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: > > > > Is 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