genpeimg replacement or application that act like it

[Jose Isaias Cabrera via Cygwin]

Greetings!

I tried using setup to install an application called 'genpeimg',

https://sources.debian.org/src/mingw-w64/10.0.0-2/mingw-w64-tools/genpeimg/

but I could not find it in the repo. Is there an application that does the same 
thing in Cygwin? Thanks.

josé

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

RE: Creating the sqlite3.exe stand-alone w/o cygwin dependency

[Jose Isaias Cabrera via Cygwin]

On December 11, 2022 3:42 PM, Michael Soegtrop  expressed:
> 
> Hi José,
> 
> Yes, I did. I think you missed one of my emails. But, here is what I did:
> > $ ldd sqlite3.exe
> >  ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll 
> > (0x7ffc1d6f)
> >  ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x778c)
> >  wow64.dll => /cygdrive/c/Windows/System32/wow64.dll 
> > (0x7ffc1c83)
> >  wow64win.dll => /cygdrive/c/Windows/System32/wow64win.dll
> > (0x7ffc1d54)
> 
> Ah, you compiled a 32 bit executable - I guess on a 64 bit install of cygwin.
> 
> Try
> 
> ./configure --host=x86_64-w64-mingw32 CFLAGS=-shared CFLAGS=-static-libgcc

Yes, I need the 32 bit DLL because the application that I have is 32 bit 
application. However, now that you mention it below, and thanks, I will build 
the 64 bit CLI. Thanks a lot.

> As far as I can tell compiling 32 bit apps on 64 bit cygwin did never work 
> (easily). 

It actually works for me with a command. But, thanks for your support. You have 
gotten me much farther.

josé

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

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

[Frank Redeker 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 
#include 

int main(int argc, char ** argv) {
   char buffer[PATH_MAX];

   argc--; argv++;
   if (argc) {
  char *   dummy;

  GetFullPathName(*argv, sizeof(buffer), buffer, );
  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


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

Re: [ATTN MAINTAINER] tig

[Adam Dinwoodie via Cygwin-apps]

On Sun, Dec 11, 2022 at 11:15:35PM +0100, Libor Ukropec via Cygwin-apps wrote:
> Hello Jari,
> 
> cygwin contains "tig" in version 2.4.1 (2019-07-30) and there's already
> 2.5.4 (2021) with many bug fixes and improvements available.
> Can I kindly ask whether it is possible to update the package?
> I do not see a git repository for the tig package, so I attached the cygport
> file if it can save you some effort (in compare to the following scallywag,
> I've added the LICENSE info the script)
> 
> Scallywag report is here: 
> https://github.com/cygwin/scallywag/actions/runs/3670966767

I believe Jari's repo for the tig Cygwin packaging is on GitHub[0], and
it looks like it's using the old pre-Cygport packaging mechanism.  I've
not looked through that repo myself (yet, at least) but it looks like
there are some patches that imply a naïve build might not work
perfectly.  Or those packages might be entirely obsolete...

[0]: https://github.com/jaalto/cygwin-package--tig

FWIW, I'd be happy to at least attempt to add this package to my small
Cygwin Git packaging empire, and take responsibility for keeping it up
to date going forwards.  But that's only if Jari wants to relinquish
that hat, and even then I think Libor clearly gets first refusal given
they've written the new Cygport file.

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

[Corinna Vinschen via 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

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

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

[Corinna Vinschen via 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

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

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

[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

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

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

[Lavrentiev, Anton (NIH/NLM/NCBI) [C] via 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


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

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

[Lavrentiev, Anton (NIH/NLM/NCBI) [C] via 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


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

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

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

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  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 
> Cc: Corinna Vinschen 
> 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
> mldata=05%7C01%7Clavr%40ncbi.nlm.nih.gov%7Cd8d314261166420bae3708dadc50a687%7C14b7757
> 8977342d58507251ca2dc2b06%7C0%7C0%7C638064536187844564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=FuakF1gx
> ayFddTTMMTvLyBJajHV6CuHlnjQg7AWYGsU%3Dreserved=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%7Csdata=ImlAyT9NAJ7Nj9c
> %2BhE2MO96kv52TUpROkVR9Fy%2B79FA%3Dreserved=0
> Documentation:
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcygwin.com%2Fdocs.html
> mp;data=05%7C01%7Clavr%40ncbi.nlm.nih.gov%7Cd8d314261166420bae3708dadc50a687%7C14b77578977
> 342d58507251ca2dc2b06%7C0%7C0%7C638064536188000791%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=7Cl2FZK52MSG
> InyHOVhLuMhc9DleUzqzwyrO2KA8ehc%3Dreserved=0
> Unsubscribe info:
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcygwin.com%2Fml%2F%23uns
> ubscribe-
> simpledata=05%7C01%7Clavr%40ncbi.nlm.nih.gov%7Cd8d314261166420bae3708dadc50a687%7C14b
> 77578977342d58507251ca2dc2b06%7C0%7C0%7C638064536188000791%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=n9Vb
> 3KyRegZz0w7KUVXBRINFFyH1ggWal%2BLvWQUzNqM%3Dreserved=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.


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

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

[Corinna Vinschen via 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

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

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

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

> 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://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: Git v2.38.2

[Adam Dinwoodie via Cygwin]

Version 2.38.2-1 of Git has been uploaded to the Cygwin distribution
servers, and should be coming soon to a mirror near you.

Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with
speed and efficiency.

This is an update to the latest upstream release, and includes the
following packages:

- git
- git-cvs
- git-debuginfo
- git-email
- git-gui
- gitk
- git-p4
- git-svn

Key extracts from the changelog:

> This is to backport various fixes accumulated during the development
> towards Git 2.39, the next feature release.

For a full list of the upstream changes in this release, please refer to
the upstream changelogs:

https://git.kernel.org/cgit/git/git.git/tree/Documentation/RelNotes
https://kernel.googlesource.com/pub/scm/git/git.git/+/master/Documentation/RelNotes/
https://github.com/git/git/tree/master/Documentation/RelNotes

Enjoy!

Adam

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

Updated: Git v2.38.2

[Adam Dinwoodie]

Version 2.38.2-1 of Git has been uploaded to the Cygwin distribution
servers, and should be coming soon to a mirror near you.

Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with
speed and efficiency.

This is an update to the latest upstream release, and includes the
following packages:

- git
- git-cvs
- git-debuginfo
- git-email
- git-gui
- gitk
- git-p4
- git-svn

Key extracts from the changelog:

> This is to backport various fixes accumulated during the development
> towards Git 2.39, the next feature release.

For a full list of the upstream changes in this release, please refer to
the upstream changelogs:

https://git.kernel.org/cgit/git/git.git/tree/Documentation/RelNotes
https://kernel.googlesource.com/pub/scm/git/git.git/+/master/Documentation/RelNotes/
https://github.com/git/git/tree/master/Documentation/RelNotes

Enjoy!

Adam

Re: Strange behavior when executing programs

[Corinna Vinschen via Cygwin]

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 (, _u_uncp, TRUE)
- && !RtlEqualUnicodePathPrefix (, _u_uncp, TRUE))
+ if (!RtlEqualUnicodePathPrefix (, _u_uncp, TRUE)
+ && (RtlEqualUnicodePathPrefix (, _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

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

Re: Strange behavior when executing programs

[Frank Redeker via 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


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

Re: Strange behavior when executing programs

[Corinna Vinschen via 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

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

Re: Regarding EFBIG error while opening a file using catopen() function

[Corinna Vinschen via Cygwin]

It's somewhat rude to send such a request to everybody and the kitchen
sink.

This belong on the cygwin ML, so please keep it here.

On Dec 12 10:40, Kavita Gore via Cygwin wrote:
> Hi all,
> 
> I'm getting errno 27[EFBIG] file too large while opening catalogue with
> catopen() function in the cygwin-32bit version.
> 
>  [...]
> #define FILENAMETEMP.CAT
> 
>buffer = catopen(FILENAME, 0);
> if (buffer != (nl_catd) - 1)
>  {
> printf("File open successfully");
> }
> else
> {
> printf("errno: %d\n", errno);
> }
> 
> While debugging using gdb.I've found that st.st_size is 0 and As per my
> understanding struct stat.st_size is declared as off_t, which is most
> probably signed, and resolves to long (signed by default).

Since you're running gdb anyway, why don't you *ask* gdb what type
off_t is?

  (gdb) ptype off_t
  type = long long

> So if SIZE_T_MAX does not fit into 2^31-1 (it most probably does not) it
> will appear as negative in the comparison.

No, under implicit type conversion rules, the comparison is well
defined.  size_t is 32 bit on 32 bit systems, off_t is 64 bit.  So the
comparison will convert __SIZE_MAX__ losslessly to long long.  On 64 bit
systems, size_t is 64 bit, off_t is 64 bit.  The comparison will be
performed unsigned, thus it will never be true.

$ cat > x.c <
#include 

int
main (int argc, char **argv)
{
  off_t o = strtoll (argv[1], NULL, 0);

  if (o > __SIZE_MAX__)
puts ("too big");
}
EOF
$ gcc -g -o x x.c

On 32 bit:

$ ./x 0
$ ./x 1
$ ./x 0x
$ ./x 0x1
too big

On 64 bit:

$ ./x 0
$ ./x 1
$ ./x 0x
$ ./x 0x1
$ ./x 0x
$ ./x 0x7fff
$


> I'd like to know the reason why I'm getting this error and How it can be
> resolved as it is a blocker in my task.

You may have to debug this a bit further.


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

Strange behavior when executing programs

[Frank Redeker via 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 



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 



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

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