Strange behavior when executing programs

Strange behavior when executing programs

[Frank Redeker]

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

Re: Strange behavior when executing programs

[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

Re: Strange behavior when executing programs

[Frank Redeker]

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

Re: Strange behavior when executing programs

[Corinna Vinschen]

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

RE: [EXTERNAL] Re: Strange behavior when executing programs

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> 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

Re: [EXTERNAL] Re: Strange behavior when executing programs

[Corinna Vinschen]

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

RE: [EXTERNAL] Re: Strange behavior when executing programs

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

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&amp;data=05%7C01%7Clavr%40ncbi.nlm.nih.gov%7Cd8d314261166420bae3708dadc50a687%7C14b7757
> 8977342d58507251ca2dc2b06%7C0%7C0%7C638064536187844564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=FuakF1gx
> ayFddTTMMTvLyBJajHV6CuHlnjQg7AWYGsU%3D&amp;reserved=0
> FAQ:
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcygwin.com%2Ffaq%2F&amp;
> data=05%7C01%7Clavr%40ncbi.nlm.nih.gov%7Cd8d314261166420bae3708dadc50a687%7C14b77578977342
> d58507251ca2dc2b06%7C0%7C0%7C638064536188000791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=ImlAyT9NAJ7Nj9c
> %2BhE2MO96kv52TUpROkVR9Fy%2B79FA%3D&amp;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&amp;sdata=7Cl2FZK52MSG
> InyHOVhLuMhc9DleUzqzwyrO2KA8ehc%3D&amp;reserved=0
> Unsubscribe info:
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcygwin.com%2Fml%2F%23uns
> ubscribe-
> simple&amp;data=05%7C01%7Clavr%40ncbi.nlm.nih.gov%7Cd8d314261166420bae3708dadc50a687%7C14b
> 77578977342d58507251ca2dc2b06%7C0%7C0%7C638064536188000791%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=n9Vb
> 3KyRegZz0w7KUVXBRINFFyH1ggWal%2BLvWQUzNqM%3D&amp;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.

RE: [EXTERNAL] Re: Strange behavior when executing programs

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> 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

RE: [EXTERNAL] Re: Strange behavior when executing programs

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

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

Re: [EXTERNAL] Re: Strange behavior when executing programs

[Corinna Vinschen]

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

Re: [EXTERNAL] Re: Strange behavior when executing programs

[Corinna Vinschen]

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

Re: [EXTERNAL] Re: Strange behavior when executing programs

[Corinna Vinschen]

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

Re: [EXTERNAL] Re: Strange behavior when executing programs

[Frank Redeker]

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

Re: Strange behavior when executing programs

[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

Re: Strange behavior when executing programs

[Frank Redeker]

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

Re: Strange behavior when executing programs

[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

Re: Strange behavior when executing programs

[Frank Redeker]

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

Re: Strange behavior when executing programs

[Jon Turney]

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

Re: Strange behavior when executing programs

[Oskar Skog]

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

Re: Strange behavior when executing programs

[Frank Redeker]

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

Re: Strange behavior when executing programs

[Corinna Vinschen]

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