X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ADE38385559E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1692008556;
	bh=BOnYxTJf8tRZeZHsVlu7ZztzujTu8gN0gUsolhIeuuc=;
	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=PyxWhOObBqJ2XTaTg0coLLjX1LAvZeAfk1qZ2C8xOyC9bnphiXXMo0kXph1akYI3o
	 uf26idaso5oZ152f3TZDDj0wgOIQuA3p67UfU/hU5rljQKpg3UdGS4H4GO2dl/Aak7
	 Lph0QluBKZG73uZ8VlVf4LFECqzk/NES1vBHIGB4=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 550463856DFE
Date: Mon, 14 Aug 2023 12:21:59 +0200
To: "Mainz, Roland" <Roland DOT Mainz AT rovema DOT de>
Subject: Re: Weird (path) problems with cygwin test release
 3.5.0-0.384.g9939aa7d0945.x86_64 ...
Message-ID: <ZNoAR4fBMXknsn5z@calimero.vinschen.de>
Mail-Followup-To: "Mainz, Roland" <Roland DOT Mainz AT rovema DOT de>,
 "cygwin AT cygwin DOT com" <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>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AM5PR0502MB30752878C878948E660A73179210A@AM5PR0502MB3075.eurprd05.prod.outlook.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" <cygwin AT cygwin DOT com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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>

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

-- 
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