* Strange behavior when executing programs @ 2022-12-12 10:21 Frank Redeker 2022-12-12 12:12 ` Corinna Vinschen 0 siblings, 1 reply; 21+ messages in thread From: Frank Redeker @ 2022-12-12 10:21 UTC (permalink / raw) To: cygwin Hello List, I have a strange behavior when the executing a program in a shell. I'm on Windows 10 Version 22H2 (OS Build 19045.2251). The strange behavior occurs when the current directory is on a drive created with subst. Originally I found the problem in a MSYS shell and already reported the problem here https://github.com/msys2/msys2.github.io/issues/234. In a reply someone asked me to check how it behaves under cygwin. Here are the steps to reproduce the problem. Inside a Windows CMD C:\Users\f.redeker>subst s: "C:\Program Files\Common Files\System" C:\Users\f.redeker>subst S:\: => C:\Program Files\Common Files\System On a computer with an older cygwin intallation $ uname -a CYGWIN_NT-6.1-WOW Mimir 2.9.0(0.318/5/3) 2017-09-12 10:41 i686 Cygwin $ sh --version GNU bash, version 4.4.12(3)-release (i686-pc-cygwin) Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. $ pwd /cygdrive/s/ado $ realpath /cygdrive/s/ado/msadox.dll /cygdrive/s/ado/msadox.dll $ realpath msadox.dll /cygdrive/s/ado/msadox.dll On a computer with a more actual version, $ uname -a CYGWIN_NT-10.0-19045 MIMIR-2 3.3.6-341.x86_64 2022-09-05 11:15 UTC x86_64 Cygwin $ sh --version GNU bash, version 4.4.12(3)-release (x86_64-unknown-cygwin) Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. $ pwd /cygdrive/s/ado $ realpath /cygdrive/s/ado/msadox.dll /cygdrive/s/ado/msadox.dll $ realpath msadox.dll /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll Is there any way to restore the old behavior. Since with the new behavior my tests no longer work. Mit freundlichen Grüßen / Best Regards Frank Redeker ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Strange behavior when executing programs 2022-12-12 10:21 Strange behavior when executing programs Frank Redeker @ 2022-12-12 12:12 ` Corinna Vinschen 2022-12-12 12:46 ` Frank Redeker 2022-12-12 14:52 ` [EXTERNAL] " Lavrentiev, Anton (NIH/NLM/NCBI) [C] 0 siblings, 2 replies; 21+ messages in thread From: Corinna Vinschen @ 2022-12-12 12:12 UTC (permalink / raw) To: Frank Redeker; +Cc: cygwin On Dec 12 11:21, Frank Redeker via Cygwin wrote: > $ pwd > /cygdrive/s/ado > > $ realpath /cygdrive/s/ado/msadox.dll > /cygdrive/s/ado/msadox.dll > > $ realpath msadox.dll > /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll > > > Is there any way to restore the old behavior. Since with the new behavior my > tests no longer work. It's not easy. If we remove the new behaviour entirely, we break other scenarios which were broken in the old version. While it *seems* easy to fix your specific scenario, it will break again as soon as the substitution drive is used inside a native symlink. Virtual drive letters were always a problem and it doesn't get easier with Windows functions not allowing to specify whether one wants to follow symlinks or virt drives in inner path components or not. Let's consider this problem again, but I don't see a quick and easy solution. Corinna ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Strange behavior when executing programs 2022-12-12 12:12 ` Corinna Vinschen @ 2022-12-12 12:46 ` Frank Redeker 2022-12-12 13:09 ` Corinna Vinschen 2022-12-12 14:52 ` [EXTERNAL] " Lavrentiev, Anton (NIH/NLM/NCBI) [C] 1 sibling, 1 reply; 21+ messages in thread From: Frank Redeker @ 2022-12-12 12:46 UTC (permalink / raw) To: cygwin Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen: > On Dec 12 11:21, Frank Redeker via Cygwin wrote: >> $ pwd >> /cygdrive/s/ado >> >> $ realpath /cygdrive/s/ado/msadox.dll >> /cygdrive/s/ado/msadox.dll >> >> $ realpath msadox.dll >> /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll >> >> >> Is there any way to restore the old behavior. Since with the new behavior my >> tests no longer work. > > It's not easy. If we remove the new behaviour entirely, we break > other scenarios which were broken in the old version. While it > *seems* easy to fix your specific scenario, it will break again > as soon as the substitution drive is used inside a native symlink. > > Virtual drive letters were always a problem and it doesn't get easier > with Windows functions not allowing to specify whether one wants to > follow symlinks or virt drives in inner path components or not. > > Let's consider this problem again, but I don't see a quick and easy > solution. > > > Corinna Hello Corinna, I am willing to create my own version, tailored to my needs. It would be nice if you could provide me with the commit that was used to implement the new behavior. (I guess the change is found inside the *git://sourceware.org/git/newlib-cygwin.git* repository) Frank ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Strange behavior when executing programs 2022-12-12 12:46 ` Frank Redeker @ 2022-12-12 13:09 ` Corinna Vinschen 2022-12-13 9:51 ` Corinna Vinschen 0 siblings, 1 reply; 21+ messages in thread From: Corinna Vinschen @ 2022-12-12 13:09 UTC (permalink / raw) To: cygwin; +Cc: Frank Redeker On Dec 12 13:46, Frank Redeker via Cygwin wrote: > Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen: > > On Dec 12 11:21, Frank Redeker via Cygwin wrote: > > > $ pwd > > > /cygdrive/s/ado > > > > > > $ realpath /cygdrive/s/ado/msadox.dll > > > /cygdrive/s/ado/msadox.dll > > > > > > $ realpath msadox.dll > > > /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll > > > > > > > > > Is there any way to restore the old behavior. Since with the new behavior my > > > tests no longer work. > > > > It's not easy. If we remove the new behaviour entirely, we break > > other scenarios which were broken in the old version. While it > > *seems* easy to fix your specific scenario, it will break again > > as soon as the substitution drive is used inside a native symlink. > > > > Virtual drive letters were always a problem and it doesn't get easier > > with Windows functions not allowing to specify whether one wants to > > follow symlinks or virt drives in inner path components or not. > > > > Let's consider this problem again, but I don't see a quick and easy > > solution. > > > > > > Corinna > Hello Corinna, I am willing to create my own version, tailored to my needs. Before you do that and decouple yourself from development, I'd suggest to look for a workaround in your code, or to see if we can't patch this behaviour in the upstream code. > It would be nice if you could provide me with the commit that was used to > implement the new behavior. (I guess the change is found inside the > *git://sourceware.org/git/newlib-cygwin.git* repository) Yes, but it's a group of patches trying to fix native symlink behaviour, spread over a couple of iterations. If you're looking for an easy workaround for your case, try this: diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc index e7619270a269..131c7e88278f 100644 --- a/winsup/cygwin/path.cc +++ b/winsup/cygwin/path.cc @@ -3492,8 +3492,10 @@ restart: { /* Check if the final path is an UNC path and the incoming path isn't. If so... */ - if (RtlEqualUnicodePathPrefix (&fpath, &ro_u_uncp, TRUE) - && !RtlEqualUnicodePathPrefix (&upath, &ro_u_uncp, TRUE)) + if (!RtlEqualUnicodePathPrefix (&upath, &ro_u_uncp, TRUE) + && (RtlEqualUnicodePathPrefix (&fpath, &ro_u_uncp, TRUE) + || towupper (upath.Buffer[4]) + != towupper (fpath.Buffer[4]))) { /* ...get the remote path, replace remote path with drive letter, check again. */ However, a generic solution would be preferrable, and a local patch to your scripts would be the better workaround for now. Corinna ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Strange behavior when executing programs 2022-12-12 13:09 ` Corinna Vinschen @ 2022-12-13 9:51 ` Corinna Vinschen 2022-12-13 12:54 ` Frank Redeker 2022-12-14 5:38 ` Frank Redeker 0 siblings, 2 replies; 21+ messages in thread From: Corinna Vinschen @ 2022-12-13 9:51 UTC (permalink / raw) To: cygwin; +Cc: Frank Redeker On Dec 12 14:09, Corinna Vinschen via Cygwin wrote: > On Dec 12 13:46, Frank Redeker via Cygwin wrote: > > Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen: > > > On Dec 12 11:21, Frank Redeker via Cygwin wrote: > > > > $ pwd > > > > /cygdrive/s/ado > > > > > > > > $ realpath /cygdrive/s/ado/msadox.dll > > > > /cygdrive/s/ado/msadox.dll > > > > > > > > $ realpath msadox.dll > > > > /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll > > > > [...] > However, a generic solution would be preferrable, and a local patch > to your scripts would be the better workaround for now. Please test cygwin-3.5.0-0.30.g5ba5e09b9d39. It contains a patch trying to workaround the problem. Thanks, Corinna ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Strange behavior when executing programs 2022-12-13 9:51 ` Corinna Vinschen @ 2022-12-13 12:54 ` Frank Redeker 2022-12-13 14:15 ` Corinna Vinschen 2022-12-14 5:38 ` Frank Redeker 1 sibling, 1 reply; 21+ messages in thread From: Frank Redeker @ 2022-12-13 12:54 UTC (permalink / raw) To: cygwin Am 12/13/2022 um 10:51 AM schrieb Corinna Vinschen: > On Dec 12 14:09, Corinna Vinschen via Cygwin wrote: >> On Dec 12 13:46, Frank Redeker via Cygwin wrote: >>> Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen: >>>> On Dec 12 11:21, Frank Redeker via Cygwin wrote: >>>>> $ pwd >>>>> /cygdrive/s/ado >>>>> >>>>> $ realpath /cygdrive/s/ado/msadox.dll >>>>> /cygdrive/s/ado/msadox.dll >>>>> >>>>> $ realpath msadox.dll >>>>> /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll >>>>> [...] >> However, a generic solution would be preferrable, and a local patch >> to your scripts would be the better workaround for now. > > Please test cygwin-3.5.0-0.30.g5ba5e09b9d39. It contains a patch > trying to workaround the problem. > > > Thanks, > Corinna Hello Corinna, I will try it out. Can you tell me where I can find the built cygwin.dll? Or do I have to build the DLL myself. Frank ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Strange behavior when executing programs 2022-12-13 12:54 ` Frank Redeker @ 2022-12-13 14:15 ` Corinna Vinschen 2022-12-13 16:35 ` Frank Redeker 0 siblings, 1 reply; 21+ messages in thread From: Corinna Vinschen @ 2022-12-13 14:15 UTC (permalink / raw) To: cygwin; +Cc: Frank Redeker On Dec 13 13:54, Frank Redeker via Cygwin wrote: > > > Am 12/13/2022 um 10:51 AM schrieb Corinna Vinschen: > > On Dec 12 14:09, Corinna Vinschen via Cygwin wrote: > > > On Dec 12 13:46, Frank Redeker via Cygwin wrote: > > > > Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen: > > > > > On Dec 12 11:21, Frank Redeker via Cygwin wrote: > > > > > > $ pwd > > > > > > /cygdrive/s/ado > > > > > > > > > > > > $ realpath /cygdrive/s/ado/msadox.dll > > > > > > /cygdrive/s/ado/msadox.dll > > > > > > > > > > > > $ realpath msadox.dll > > > > > > /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll > > > > > > [...] > > > However, a generic solution would be preferrable, and a local patch > > > to your scripts would be the better workaround for now. > > > > Please test cygwin-3.5.0-0.30.g5ba5e09b9d39. It contains a patch > > trying to workaround the problem. > > > > > > Thanks, > > Corinna > Hello Corinna, > > I will try it out. Can you tell me where I can find the built cygwin.dll? Or > do I have to build the DLL myself. https://cygwin.com/faq.html#faq.api.testrels ;) Corinna ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Strange behavior when executing programs 2022-12-13 14:15 ` Corinna Vinschen @ 2022-12-13 16:35 ` Frank Redeker 2022-12-13 16:54 ` Jon Turney 0 siblings, 1 reply; 21+ messages in thread From: Frank Redeker @ 2022-12-13 16:35 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2507 bytes --] Am 12/13/2022 um 3:15 PM schrieb Corinna Vinschen: > On Dec 13 13:54, Frank Redeker via Cygwin wrote: >> >> >> Am 12/13/2022 um 10:51 AM schrieb Corinna Vinschen: >>> On Dec 12 14:09, Corinna Vinschen via Cygwin wrote: >>>> On Dec 12 13:46, Frank Redeker via Cygwin wrote: >>>>> Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen: >>>>>> On Dec 12 11:21, Frank Redeker via Cygwin wrote: >>>>>>> $ pwd >>>>>>> /cygdrive/s/ado >>>>>>> >>>>>>> $ realpath /cygdrive/s/ado/msadox.dll >>>>>>> /cygdrive/s/ado/msadox.dll >>>>>>> >>>>>>> $ realpath msadox.dll >>>>>>> /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll >>>>>>> [...] >>>> However, a generic solution would be preferrable, and a local patch >>>> to your scripts would be the better workaround for now. >>> >>> Please test cygwin-3.5.0-0.30.g5ba5e09b9d39. It contains a patch >>> trying to workaround the problem. >>> >>> >>> Thanks, >>> Corinna >> Hello Corinna, >> >> I will try it out. Can you tell me where I can find the built cygwin.dll? Or >> do I have to build the DLL myself. > > https://cygwin.com/faq.html#faq.api.testrels ;) > > > Corinna Hello Corrina, I tried to install in fresh VM without success. (No AV installed and the Windows Firewall is off) 2022/12/13 17:04:42 Starting cygwin install, version 2.924 2022/12/13 17:04:42 User has backup/restore rights 2022/12/13 17:04:42 User has symlink creation right 2022/12/13 17:04:42 io_stream_cygfile: fopen(/etc/setup/setup.rc) failed 2 No such file or directory 2022/12/13 17:04:42 Current Directory: D:\Program_Files_64\cygwin64\downloads Could not open service McShield for query, start and stop. McAfee may not be installed, or we don't have access. 2022/12/13 17:04:49 source: download 2022/12/13 17:04:51 Selected local directory: D:\Program_Files_64\cygwin64\downloads 2022/12/13 17:04:55 net: Direct Cached mirror list unavailable User-Agent: default is "Cygwin-Setup/2.924 (Windows NT 10.0.18362;Win64;0407;SymLinkPriv)" 2022/12/13 17:05:25 connection error: 12057 fetching https://cygwin.com/mirrors.lst 2022/12/13 17:05:25 mbox note: Could not download mirror sites list Defaulting to empty mirror list 2022/12/13 17:11:52 net: Direct 2022/12/13 17:11:56 mbox : Are you sure you want to exit setup? Any current download or installation will be aborted. 2022/12/13 17:11:58 io_stream_cygfile: fopen(/etc/setup/setup.rc) failed 2 No such file or directory 2022/12/13 17:11:58 Ending cygwin install Maybe the stripped ProcMon logfile is helpful. Frank [-- Attachment #2: procmon.cvs --] [-- Type: text/plain, Size: 2977 bytes --] "Process Name","Operation","Path","Result","Detail" "setup-x86_64.exe","TCP Connect","MIMIR-W10-64:51462 -> server2.sourceware.org:https","SUCCESS","Length: 0, mss: 1460, sackopt: 0, tsopt: 0, wsopt: 0, rcvwin: 65535, rcvwinscale: 0, sndwinscale: 0, seqnum: 0, connid: 0" "setup-x86_64.exe","TCP Send","MIMIR-W10-64:51462 -> server2.sourceware.org:https","SUCCESS","Length: 171, startime: 8228070, endtime: 8228070, seqnum: 0, connid: 0" "setup-x86_64.exe","TCP TCPCopy","MIMIR-W10-64:51462 -> server2.sourceware.org:https","SUCCESS","Length: 1420, seqnum: 0, connid: 0" "setup-x86_64.exe","TCP Receive","MIMIR-W10-64:51462 -> server2.sourceware.org:https","SUCCESS","Length: 1420, seqnum: 0, connid: 0" "setup-x86_64.exe","TCP TCPCopy","MIMIR-W10-64:51462 -> server2.sourceware.org:https","SUCCESS","Length: 1420, seqnum: 0, connid: 0" "setup-x86_64.exe","TCP Receive","MIMIR-W10-64:51462 -> server2.sourceware.org:https","SUCCESS","Length: 1420, seqnum: 0, connid: 0" "setup-x86_64.exe","TCP TCPCopy","MIMIR-W10-64:51462 -> server2.sourceware.org:https","SUCCESS","Length: 1420, seqnum: 0, connid: 0" "setup-x86_64.exe","TCP Receive","MIMIR-W10-64:51462 -> server2.sourceware.org:https","SUCCESS","Length: 1420, seqnum: 0, connid: 0" "setup-x86_64.exe","TCP TCPCopy","MIMIR-W10-64:51462 -> server2.sourceware.org:https","SUCCESS","Length: 200, seqnum: 0, connid: 0" "setup-x86_64.exe","TCP Receive","MIMIR-W10-64:51462 -> server2.sourceware.org:https","SUCCESS","Length: 200, seqnum: 0, connid: 0" "setup-x86_64.exe","TCP Reconnect","MIMIR-W10-64:51463 -> xxx.static.arcor-ip.net:8000","SUCCESS","Length: 0, seqnum: 0, connid: 0" "setup-x86_64.exe","TCP Reconnect","MIMIR-W10-64:51463 -> xxx.static.arcor-ip.net:8000","SUCCESS","Length: 0, seqnum: 0, connid: 0" "setup-x86_64.exe","TCP Reconnect","MIMIR-W10-64:51463 -> xxx.static.arcor-ip.net:8000","SUCCESS","Length: 0, seqnum: 0, connid: 0" "setup-x86_64.exe","TCP Reconnect","MIMIR-W10-64:51463 -> xxx.static.arcor-ip.net:8000","SUCCESS","Length: 0, seqnum: 0, connid: 0" "setup-x86_64.exe","TCP Reconnect","MIMIR-W10-64:51464 -> xxx.static.arcor-ip.net:8000","SUCCESS","Length: 0, seqnum: 0, connid: 0" "setup-x86_64.exe","TCP Reconnect","MIMIR-W10-64:51464 -> xxx.static.arcor-ip.net:8000","SUCCESS","Length: 0, seqnum: 0, connid: 0" "setup-x86_64.exe","TCP Disconnect","MIMIR-W10-64:51463 -> xxx.static.arcor-ip.net:8000","SUCCESS","Length: 0, seqnum: 0, connid: 0" "setup-x86_64.exe","TCP Reconnect","MIMIR-W10-64:51464 -> xxx.static.arcor-ip.net:8000","SUCCESS","Length: 0, seqnum: 0, connid: 0" "setup-x86_64.exe","TCP Reconnect","MIMIR-W10-64:51464 -> xxx.static.arcor-ip.net:8000","SUCCESS","Length: 0, seqnum: 0, connid: 0" "setup-x86_64.exe","TCP Disconnect","MIMIR-W10-64:51462 -> server2.sourceware.org:https","SUCCESS","Length: 0, seqnum: 0, connid: 0" "setup-x86_64.exe","TCP Disconnect","MIMIR-W10-64:51464 -> xxx.static.arcor-ip.net:8000","SUCCESS","Length: 0, seqnum: 0, connid: 0" ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Strange behavior when executing programs 2022-12-13 16:35 ` Frank Redeker @ 2022-12-13 16:54 ` Jon Turney 2022-12-13 17:04 ` Oskar Skog 0 siblings, 1 reply; 21+ messages in thread From: Jon Turney @ 2022-12-13 16:54 UTC (permalink / raw) To: Frank Redeker, The Cygwin Mailing List On 13/12/2022 16:35, Frank Redeker via Cygwin wrote: > I tried to install in fresh VM without success. (No AV installed and the > Windows Firewall is off) > [...] > 2022/12/13 17:04:55 net: Direct > Cached mirror list unavailable > User-Agent: default is "Cygwin-Setup/2.924 (Windows NT > 10.0.18362;Win64;0407;SymLinkPriv)" > 2022/12/13 17:05:25 connection error: 12057 fetching > https://cygwin.com/mirrors.lst > 2022/12/13 17:05:25 mbox note: Could not download mirror sites list > Defaulting to empty mirror list The meaning of the 12057 error isn't clear, but it seems to mean you are behind a proxy, which isn't co-operating. (See e.g. [1]) [1] https://cygwin.com/pipermail/cygwin/2022-February/250814.html You could work around the inability to fetch the mirror list (the only piece of information setup tries to get from cygwin.com), by explicitly specifying one from [2] [2] https://cygwin.com/mirrors.html ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Strange behavior when executing programs 2022-12-13 16:54 ` Jon Turney @ 2022-12-13 17:04 ` Oskar Skog 0 siblings, 0 replies; 21+ messages in thread From: Oskar Skog @ 2022-12-13 17:04 UTC (permalink / raw) To: cygwin On 2022-12-13 18:54, Jon Turney via Cygwin wrote: > On 13/12/2022 16:35, Frank Redeker via Cygwin wrote: > >> I tried to install in fresh VM without success. (No AV installed and >> the Windows Firewall is off) >> > [...] >> 2022/12/13 17:04:55 net: Direct >> Cached mirror list unavailable >> User-Agent: default is "Cygwin-Setup/2.924 (Windows NT >> 10.0.18362;Win64;0407;SymLinkPriv)" >> 2022/12/13 17:05:25 connection error: 12057 fetching >> https://cygwin.com/mirrors.lst >> 2022/12/13 17:05:25 mbox note: Could not download mirror sites list >> Defaulting to empty mirror list > > The meaning of the 12057 error isn't clear, but it seems to mean you are > behind a proxy, which isn't co-operating. (See e.g. [1]) > > [1] https://cygwin.com/pipermail/cygwin/2022-February/250814.html > > You could work around the inability to fetch the mirror list (the only > piece of information setup tries to get from cygwin.com), by explicitly > specifying one from [2] > > [2] https://cygwin.com/mirrors.html > > ERROR_WINHTTP_SECURE_CERT_REV_FAILED 12057 Indicates that revocation cannot be checked because the revocation server was offline (equivalent to CRYPT_E_REVOCATION_OFFLINE). https://learn.microsoft.com/en-us/windows/win32/winhttp/error-messages ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Strange behavior when executing programs 2022-12-13 9:51 ` Corinna Vinschen 2022-12-13 12:54 ` Frank Redeker @ 2022-12-14 5:38 ` Frank Redeker 2022-12-14 10:14 ` Corinna Vinschen 1 sibling, 1 reply; 21+ messages in thread From: Frank Redeker @ 2022-12-14 5:38 UTC (permalink / raw) To: cygwin Am 12/13/2022 um 10:51 AM schrieb Corinna Vinschen: > On Dec 12 14:09, Corinna Vinschen via Cygwin wrote: >> On Dec 12 13:46, Frank Redeker via Cygwin wrote: >>> Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen: >>>> On Dec 12 11:21, Frank Redeker via Cygwin wrote: >>>>> $ pwd >>>>> /cygdrive/s/ado >>>>> >>>>> $ realpath /cygdrive/s/ado/msadox.dll >>>>> /cygdrive/s/ado/msadox.dll >>>>> >>>>> $ realpath msadox.dll >>>>> /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll >>>>> [...] >> However, a generic solution would be preferrable, and a local patch >> to your scripts would be the better workaround for now. > > Please test cygwin-3.5.0-0.30.g5ba5e09b9d39. It contains a patch > trying to workaround the problem. > > > Thanks, > Corinna Hello Corinna, thanks for your patch. It works as expected. $ uname -a CYGWIN_NT-10.0-22000 W11-DEVELOP 3.5.0-0.30.g5ba5e09b9d39.x86_64 2022-12-12 21:37 UTC x86_64 Cygwin $ pwd /cygdrive/s/ado $ realpath msadox.dll /cygdrive/s/ado/msadox.dll $ sample.exe msadox.dll [msadox.dll] -> [S:\ado\msadox.dll] Frank ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Strange behavior when executing programs 2022-12-14 5:38 ` Frank Redeker @ 2022-12-14 10:14 ` Corinna Vinschen 0 siblings, 0 replies; 21+ messages in thread From: Corinna Vinschen @ 2022-12-14 10:14 UTC (permalink / raw) To: cygwin On Dec 14 06:38, Frank Redeker via Cygwin wrote: > > > Am 12/13/2022 um 10:51 AM schrieb Corinna Vinschen: > > On Dec 12 14:09, Corinna Vinschen via Cygwin wrote: > > > On Dec 12 13:46, Frank Redeker via Cygwin wrote: > > > > Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen: > > > > > On Dec 12 11:21, Frank Redeker via Cygwin wrote: > > > > > > $ pwd > > > > > > /cygdrive/s/ado > > > > > > > > > > > > $ realpath /cygdrive/s/ado/msadox.dll > > > > > > /cygdrive/s/ado/msadox.dll > > > > > > > > > > > > $ realpath msadox.dll > > > > > > /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll > > > > > > [...] > > > However, a generic solution would be preferrable, and a local patch > > > to your scripts would be the better workaround for now. > > > > Please test cygwin-3.5.0-0.30.g5ba5e09b9d39. It contains a patch > > trying to workaround the problem. > > > > > > Thanks, > > Corinna > Hello Corinna, > > thanks for your patch. It works as expected. > > $ uname -a > CYGWIN_NT-10.0-22000 W11-DEVELOP 3.5.0-0.30.g5ba5e09b9d39.x86_64 2022-12-12 > 21:37 UTC x86_64 Cygwin > > $ pwd > /cygdrive/s/ado > > $ realpath msadox.dll > /cygdrive/s/ado/msadox.dll > > $ sample.exe msadox.dll > [msadox.dll] -> [S:\ado\msadox.dll] Great, thanks for testing! Corinna ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [EXTERNAL] Re: Strange behavior when executing programs 2022-12-12 12:12 ` Corinna Vinschen 2022-12-12 12:46 ` Frank Redeker @ 2022-12-12 14:52 ` Lavrentiev, Anton (NIH/NLM/NCBI) [C] 2022-12-12 15:20 ` Corinna Vinschen 2022-12-12 15:22 ` Lavrentiev, Anton (NIH/NLM/NCBI) [C] 1 sibling, 2 replies; 21+ messages in thread From: Lavrentiev, Anton (NIH/NLM/NCBI) [C] @ 2022-12-12 14:52 UTC (permalink / raw) To: cygwin, Frank Redeker; +Cc: Corinna Vinschen > Let's consider this problem again, but I don't see a quick and easy > solution. $ realpath /cygdrive/s/ado/msadox.dll /cygdrive/s/ado/msadox.dll <====== IMO the problem is actually here $ realpath msadox.dll /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll Both paths should start with /cygdrive/c, and then those would be identical (and, hence, I suppose for the purposes of the OP). A substed drive is nothing BUT a symlink, should be treated no differently than /cygdrive/s -> /cygdrive/c/Program Files/Common Files/System Because even Windows shows you the same: S:\: => C:\Program Files\Common Files\System Since realpath is supposed to resolve all symlinks, it should never show any /cygdrive/s in the resultant path. My $.02, Anton Lavrentiev Contractor NIH/NLM/NCBI ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [EXTERNAL] Re: Strange behavior when executing programs 2022-12-12 14:52 ` [EXTERNAL] " Lavrentiev, Anton (NIH/NLM/NCBI) [C] @ 2022-12-12 15:20 ` Corinna Vinschen 2022-12-12 15:29 ` Lavrentiev, Anton (NIH/NLM/NCBI) [C] 2022-12-12 15:22 ` Lavrentiev, Anton (NIH/NLM/NCBI) [C] 1 sibling, 1 reply; 21+ messages in thread From: Corinna Vinschen @ 2022-12-12 15:20 UTC (permalink / raw) To: cygwin On Dec 12 14:52, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > > Let's consider this problem again, but I don't see a quick and easy > > solution. > > $ realpath /cygdrive/s/ado/msadox.dll > /cygdrive/s/ado/msadox.dll <====== IMO the problem is actually here > > $ realpath msadox.dll > /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll > > Both paths should start with /cygdrive/c, and then those would be identical > (and, hence, I suppose for the purposes of the OP). > > A substed drive is nothing BUT a symlink, should be treated no differently than > /cygdrive/s -> /cygdrive/c/Program Files/Common Files/System I agree, and that was how I tried implementing it back when. The problem is that resolved paths may become longer than MAX_PATH. So people want to keep the paths with intact substituted drive prefix to run native commands from Cygwin. Corinna ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [EXTERNAL] Re: Strange behavior when executing programs 2022-12-12 15:20 ` Corinna Vinschen @ 2022-12-12 15:29 ` Lavrentiev, Anton (NIH/NLM/NCBI) [C] 2022-12-12 15:40 ` Lavrentiev, Anton (NIH/NLM/NCBI) [C] 2022-12-12 15:42 ` Corinna Vinschen 0 siblings, 2 replies; 21+ messages in thread From: Lavrentiev, Anton (NIH/NLM/NCBI) [C] @ 2022-12-12 15:29 UTC (permalink / raw) To: cygwin > The problem is that resolved paths may become longer than MAX_PATH. Oh... But that'd be the same on any other OS that exceeds MAX_PATH, symlinking is going to help work around that, if the full path resolution was requested. BTW, about MAX_PATH -- was it Cygwin's or Windows'? If the former, can't it be enlarged? Anton Lavrentiev Contractor NIH/NLM/NCBI ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [EXTERNAL] Re: Strange behavior when executing programs 2022-12-12 15:29 ` Lavrentiev, Anton (NIH/NLM/NCBI) [C] @ 2022-12-12 15:40 ` Lavrentiev, Anton (NIH/NLM/NCBI) [C] 2022-12-12 15:42 ` Corinna Vinschen 1 sibling, 0 replies; 21+ messages in thread From: Lavrentiev, Anton (NIH/NLM/NCBI) [C] @ 2022-12-12 15:40 UTC (permalink / raw) To: cygwin Was supposed to be: > symlinking is *NOT* going to help work around that Sorry I am struggling with MS Outlook this morning Anton Lavrentiev Contractor NIH/NLM/NCBI ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [EXTERNAL] Re: Strange behavior when executing programs 2022-12-12 15:29 ` Lavrentiev, Anton (NIH/NLM/NCBI) [C] 2022-12-12 15:40 ` Lavrentiev, Anton (NIH/NLM/NCBI) [C] @ 2022-12-12 15:42 ` Corinna Vinschen 2022-12-12 15:50 ` Corinna Vinschen 1 sibling, 1 reply; 21+ messages in thread From: Corinna Vinschen @ 2022-12-12 15:42 UTC (permalink / raw) To: cygwin On Dec 12 15:29, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > > The problem is that resolved paths may become longer than MAX_PATH. > > Oh... But that'd be the same on any other OS that exceeds MAX_PATH, symlinking is going to help work around that, > if the full path resolution was requested. > > BTW, about MAX_PATH -- was it Cygwin's or Windows'? If the former, can't it be enlarged? Cygwin handles up to 32K paths for a long time, just like the Windows kernel. It's the native tools and the Win32 ANSI file-API still using MAX_PATH as a path length restriction. Corinna ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [EXTERNAL] Re: Strange behavior when executing programs 2022-12-12 15:42 ` Corinna Vinschen @ 2022-12-12 15:50 ` Corinna Vinschen 0 siblings, 0 replies; 21+ messages in thread From: Corinna Vinschen @ 2022-12-12 15:50 UTC (permalink / raw) To: cygwin On Dec 12 16:42, Corinna Vinschen via Cygwin wrote: > On Dec 12 15:29, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > > > The problem is that resolved paths may become longer than MAX_PATH. > > > > Oh... But that'd be the same on any other OS that exceeds MAX_PATH, symlinking is going to help work around that, > > if the full path resolution was requested. > > > > BTW, about MAX_PATH -- was it Cygwin's or Windows'? If the former, can't it be enlarged? > > Cygwin handles up to 32K paths for a long time, just like the Windows > kernel. > > It's the native tools and the Win32 ANSI file-API still using MAX_PATH > as a path length restriction. Oh, and for kicks: Windows only allows MAX_PATH - 2 chars as the maximum path length of the current working directory. And that's a hard restriction you can't even workaround by using the UNICODE file-API. Windows 10 1607 lifts that restriction, but it's boarded up as an opt-in option. Therefore, as a developer, you can't rely on the user machines having this enabled, so you're kind of stuck. Cygwin's CWD doesn't have that restriction, it can be up to 32K long as well because it handles this internally. Corinna ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [EXTERNAL] Re: Strange behavior when executing programs 2022-12-12 14:52 ` [EXTERNAL] " Lavrentiev, Anton (NIH/NLM/NCBI) [C] 2022-12-12 15:20 ` Corinna Vinschen @ 2022-12-12 15:22 ` Lavrentiev, Anton (NIH/NLM/NCBI) [C] 2022-12-12 15:41 ` Corinna Vinschen 1 sibling, 1 reply; 21+ messages in thread From: Lavrentiev, Anton (NIH/NLM/NCBI) [C] @ 2022-12-12 15:22 UTC (permalink / raw) To: Lavrentiev, Anton (NIH/NLM/NCBI) [C], cygwin, Frank Redeker Cc: Corinna Vinschen Sorry about the earlier typos > (and, hence, I suppose for the purposes of the OP). and, hence, I suppose, *would work* for the purposes of the OP. > Since realpath is supposed to resolve all symlinks, I meant by default (the -P behavior). If -s was asked, then the output would be corect. Anton Lavrentiev Contractor NIH/NLM/NCBI > -----Original Message----- > From: Cygwin <cygwin-bounces+lavr=ncbi.nlm.nih.gov@cygwin.com> On Behalf Of Lavrentiev, > Anton (NIH/NLM/NCBI) [C] via Cygwin > Sent: Monday, December 12, 2022 9:53 AM > To: cygwin@cygwin.com; Frank Redeker <frank.redeker@razorcat.com> > Cc: Corinna Vinschen <corinna-cygwin@cygwin.com> > Subject: RE: [EXTERNAL] Re: Strange behavior when executing programs > > > Let's consider this problem again, but I don't see a quick and easy > > solution. > > $ realpath /cygdrive/s/ado/msadox.dll > /cygdrive/s/ado/msadox.dll <====== IMO the problem is actually here > > $ realpath msadox.dll > /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll > > Both paths should start with /cygdrive/c, and then those would be identical > (and, hence, I suppose for the purposes of the OP). > > A substed drive is nothing BUT a symlink, should be treated no differently than > /cygdrive/s -> /cygdrive/c/Program Files/Common Files/System > > Because even Windows shows you the same: > S:\: => C:\Program Files\Common Files\System > > Since realpath is supposed to resolve all symlinks, it should never show any > /cygdrive/s in the resultant path. > > My $.02, > > Anton Lavrentiev > Contractor NIH/NLM/NCBI > > > > -- > Problem reports: > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcygwin.com%2Fproblems.ht > ml&data=05%7C01%7Clavr%40ncbi.nlm.nih.gov%7Cd8d314261166420bae3708dadc50a687%7C14b7757 > 8977342d58507251ca2dc2b06%7C0%7C0%7C638064536187844564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FuakF1gx > ayFddTTMMTvLyBJajHV6CuHlnjQg7AWYGsU%3D&reserved=0 > FAQ: > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcygwin.com%2Ffaq%2F& > data=05%7C01%7Clavr%40ncbi.nlm.nih.gov%7Cd8d314261166420bae3708dadc50a687%7C14b77578977342 > d58507251ca2dc2b06%7C0%7C0%7C638064536188000791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ImlAyT9NAJ7Nj9c > %2BhE2MO96kv52TUpROkVR9Fy%2B79FA%3D&reserved=0 > Documentation: > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcygwin.com%2Fdocs.html&a > mp;data=05%7C01%7Clavr%40ncbi.nlm.nih.gov%7Cd8d314261166420bae3708dadc50a687%7C14b77578977 > 342d58507251ca2dc2b06%7C0%7C0%7C638064536188000791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA > wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7Cl2FZK52MSG > InyHOVhLuMhc9DleUzqzwyrO2KA8ehc%3D&reserved=0 > Unsubscribe info: > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcygwin.com%2Fml%2F%23uns > ubscribe- > simple&data=05%7C01%7Clavr%40ncbi.nlm.nih.gov%7Cd8d314261166420bae3708dadc50a687%7C14b > 77578977342d58507251ca2dc2b06%7C0%7C0%7C638064536188000791%7CUnknown%7CTWFpbGZsb3d8eyJWIjo > iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=n9Vb > 3KyRegZz0w7KUVXBRINFFyH1ggWal%2BLvWQUzNqM%3D&reserved=0 > CAUTION: This email originated from outside of the organization. Do not click links or > open attachments unless you recognize the sender and are confident the content is safe. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [EXTERNAL] Re: Strange behavior when executing programs 2022-12-12 15:22 ` Lavrentiev, Anton (NIH/NLM/NCBI) [C] @ 2022-12-12 15:41 ` Corinna Vinschen 2022-12-12 16:40 ` Frank Redeker 0 siblings, 1 reply; 21+ messages in thread From: Corinna Vinschen @ 2022-12-12 15:41 UTC (permalink / raw) To: cygwin On Dec 12 15:22, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > Sorry about the earlier typos > > > (and, hence, I suppose for the purposes of the OP). > > and, hence, I suppose, *would work* for the purposes of the OP. > > > Since realpath is supposed to resolve all symlinks, > > I meant by default (the -P behavior). If -s was asked, then the output would be corect. Options are only available in realpath(1). As for under the hood, realpath(3) has no options so it can only return one of the alternatives. Corinna ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [EXTERNAL] Re: Strange behavior when executing programs 2022-12-12 15:41 ` Corinna Vinschen @ 2022-12-12 16:40 ` Frank Redeker 0 siblings, 0 replies; 21+ messages in thread From: Frank Redeker @ 2022-12-12 16:40 UTC (permalink / raw) To: Corinna Vinschen via Cygwin Am 12/12/2022 um 4:41 PM schrieb Corinna Vinschen via Cygwin: > On Dec 12 15:22, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: >> Sorry about the earlier typos >> >>> (and, hence, I suppose for the purposes of the OP). >> >> and, hence, I suppose, *would work* for the purposes of the OP. >> >>> Since realpath is supposed to resolve all symlinks, >> >> I meant by default (the -P behavior). If -s was asked, then the output would be corect. > > Options are only available in realpath(1). As for under the hood, > realpath(3) has no options so it can only return one of the > alternatives. > > > Corinna > I don't have a problem with *realpath* but with the fact that a native program in a cygwin or msys shell gives a different result than in a Windows CMD or older versions of cygwin and msys. Consider the following simple sample unsing the WIN32 API. (Compiled with MinGW, Borland, Visual Studio, ....) #include <windows.h> #include <stdio.h> int main(int argc, char ** argv) { char buffer[PATH_MAX]; argc--; argv++; if (argc) { char * dummy; GetFullPathName(*argv, sizeof(buffer), buffer, &dummy); printf("[%s] -> [%s]\n", *argv, buffer); } return 0; } If I execute the program from inside CMD it gives the expected result. S:\ado>sample msadox.dll [msadox.dll] -> [S:\ado\msadox.dll] From inside a bash the result depends on passed argument and/or the current working directory of the shell. f.redeker@MIMIR-2 /cygdrive/s/ado $ sample msadox.dll [msadox.dll] -> [C:\Program Files\Common Files\System\ado\msadox.dll] With Process Monitor I have observed that the shell does not execute the program directly, but starts a subshell and that subshell then starts the actual program. The created Windows Process has as working directory not S:\ado but C:\Program Files\Common Files\System\ado. But if the first argument of GetFullPathName() is a relative path, then Windows takes into account the in my eyes incorrect working directory. The same thing happens when you use GetCurrentDirectory() in your program. Frank ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2022-12-14 10:14 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-12-12 10:21 Strange behavior when executing programs Frank Redeker 2022-12-12 12:12 ` Corinna Vinschen 2022-12-12 12:46 ` Frank Redeker 2022-12-12 13:09 ` Corinna Vinschen 2022-12-13 9:51 ` Corinna Vinschen 2022-12-13 12:54 ` Frank Redeker 2022-12-13 14:15 ` Corinna Vinschen 2022-12-13 16:35 ` Frank Redeker 2022-12-13 16:54 ` Jon Turney 2022-12-13 17:04 ` Oskar Skog 2022-12-14 5:38 ` Frank Redeker 2022-12-14 10:14 ` Corinna Vinschen 2022-12-12 14:52 ` [EXTERNAL] " Lavrentiev, Anton (NIH/NLM/NCBI) [C] 2022-12-12 15:20 ` Corinna Vinschen 2022-12-12 15:29 ` Lavrentiev, Anton (NIH/NLM/NCBI) [C] 2022-12-12 15:40 ` Lavrentiev, Anton (NIH/NLM/NCBI) [C] 2022-12-12 15:42 ` Corinna Vinschen 2022-12-12 15:50 ` Corinna Vinschen 2022-12-12 15:22 ` Lavrentiev, Anton (NIH/NLM/NCBI) [C] 2022-12-12 15:41 ` Corinna Vinschen 2022-12-12 16:40 ` Frank Redeker
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).