From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2155) id 550463856DFE; Mon, 14 Aug 2023 10:22:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 550463856DFE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1692008521; bh=5V7ZyetzRhnpR/cCTZSNy/EGU50KvPY3N9dNX1nTEAI=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=aWgy9cMP2HAsX1TXPvQ5obdXYpCS/qi8WyozehUsngsx9G3AJqnXFwyBjfTW6YHDa xVNkbCxVVI46L3SNK54Y+Dfw3UMQQHrOCqPvT6FrZqu3TClqlgpO0pom/zMz3GVTyw Nr3IMlI40M6oBhWGkG5TiZp9kE13jsoesDTodc0g= Received: by calimero.vinschen.de (Postfix, from userid 500) id 6E60BA80C97; Mon, 14 Aug 2023 12:21:59 +0200 (CEST) Date: Mon, 14 Aug 2023 12:21:59 +0200 From: Corinna Vinschen To: "Mainz, Roland" 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: "Mainz, Roland" , "cygwin@cygwin.com" References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: List-Id: 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: $ 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