Re: libresolv does not provide __ns_initparse, resulting in LD undefined reference

[Corinna Vinschen via Cygwin]

On Nov  4 11:24, Corinna Vinschen via Cygwin wrote:
> On Oct 29 22:35, Named T. Relay via Cygwin wrote:
> > Hello,
> > 
> > Today i installed cygwin to compile a windows .exe out of a Linux source 
> > program.
> > While G++ on Linux compiles it correctly into a binary, on cygwin i got an 
> > issue during linking:
> > 
> > $ g++ -O2 -Wall -Isrc -o bin/sealtool  src/sign-verify.cpp -lcrypto 
> > -lssl -lcurl -lresolv
> > /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: 
> > /tmp/ccA3GExv.o:sign-verify.cp:(.text+0x437): undefined reference to 
> > `__ns_initparse'
> > /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: 
> > /tmp/ccA3GExv.o:sign-verify.cp:(.text+0x49a): undefined reference to 
> > `__ns_parserr'
> > collect2: error: ld returned 1 exit status
> > 
> > >From looking at the nm results, the provided libresolv library does not 
> > >include these symbols.
> > (But my linux distro's version of libresolv DOES have them!)
> > 
> > Does anyone know why these symbols are missing?
> 
> They have never been implemented in Cygwin itself. Cygwin only has a
> piece of source called minires, a simple resolver lib depending on
> the underlying Windows resolver, providing the res_FOO symbols from
> resolv.h.  The nameserver symbols from nameser.h are not part of the
> Cywin core lib.  Maybe you have more luck with the (unmaintained)
> bind libs?

But then again, if you use the bind libs, you have to maintain your own
/etc/resolv.conf, since the bind libs don't call the Cygwin resolver and
thus have no access to the OS resolver.


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: libresolv does not provide __ns_initparse, resulting in LD undefined reference

[Corinna Vinschen via Cygwin]

On Oct 29 22:35, Named T. Relay via Cygwin wrote:
> Hello,
> 
> Today i installed cygwin to compile a windows .exe out of a Linux source 
> program.
> While G++ on Linux compiles it correctly into a binary, on cygwin i got an 
> issue during linking:
> 
> $ g++ -O2 -Wall -Isrc -o bin/sealtool  src/sign-verify.cpp -lcrypto 
> -lssl -lcurl -lresolv
> /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: 
> /tmp/ccA3GExv.o:sign-verify.cp:(.text+0x437): undefined reference to 
> `__ns_initparse'
> /usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: 
> /tmp/ccA3GExv.o:sign-verify.cp:(.text+0x49a): undefined reference to 
> `__ns_parserr'
> collect2: error: ld returned 1 exit status
> 
> >From looking at the nm results, the provided libresolv library does not 
> >include these symbols.
> (But my linux distro's version of libresolv DOES have them!)
> 
> Does anyone know why these symbols are missing?

They have never been implemented in Cygwin itself. Cygwin only has a
piece of source called minires, a simple resolver lib depending on
the underlying Windows resolver, providing the res_FOO symbols from
resolv.h.  The nameserver symbols from nameser.h are not part of the
Cywin core lib.  Maybe you have more luck with the (unmaintained)
bind libs?


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: g++ 12 -std=gnu++20

[Corinna Vinschen via Cygwin]

On Oct 30 09:06, Brian Inglis via Cygwin wrote:
> Hi folks,
> 
> Trying to update a package using c++ (requires gcc 12.4+ for adequate c++
> 2020 support) and getting confusing error messages.
> 
> It appears that noexcept in the header files may here redefined by the
> compiler or headers as __GLIBC_NOEXCEPT.

There's one underscore too many, that should be _GLIBCXX_NOEXCEPT.

> Those errors look to me like a failure to detect that *glibc* is not 
> available.
> Or is *GLIBCXX* actually *glib* for *cxx*, so this could be a library or
> compiler issue?

It's used in the gcc c++ headers, defined in c++config.h and part of the
gcc-g++ package.  The packaging on Fedora puts this file into the
libstdc++-devel package, which is more helpful, I guess.


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: [Ms-nfs41-client-devel] Windows Server NFS, getfact not working on NFS

[Corinna Vinschen via Cygwin]

On Oct 29 15:08, Sam Edge via Cygwin wrote:
> On 29/10/2024 14:38, Corinna Vinschen via Cygwin wrote:
> > On Oct 29 13:56, Martin Wege via Cygwin wrote:
> > > No, FILE_PERSISTENT_ACLS is not in that output.
> > > 
> > > Reading 
> > > https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getvolumeinformationa
> > > it means that the Windows NFSv4.1 server does not support ACLs?
> > 
> > https://learn.microsoft.com/en-us/answers/questions/1132611/windows-nfs-server-acls
> > 
> To the point as always. :-)
> 
> However the answer in that link raises more questions.
> 
> a) Does that mean NFS-served ACLs /are/ supported by Cygwin if the "stored
> in GPFS as POSIX ACLs" caveat applies?

If the external GPFS filesystem sets the FILE_PERSISTENT_ACLS flag when
communicating with a Windows client, then yes.  Otherwise no.

> I've just been reviewing the Cygwin user guide. The following took my eye.
> 
> > noacl - Cygwin ignores filesystem ACLs and only fakes a subset of
> > permission bits based on the DOS readonly attribute. This
> > behaviour is the default on FAT and FAT32. The flag is
> > ignored on NFS filesystems.
> 
> b) Does this mean ACLs are ALWAYS support on NFS or NEVER supported?

The user guide contains this:

https://cygwin.com/cygwin-ug-net/using-filemodes.html

NFSv3 == POSIX file permission bits as in st_mode.

As I wrote months ago, the NFSv4 driver should not use "NFS" as
filesystem name, but something like "NFS4". This way, the two
filesystems can be distinguished and handled separately.  Given that
Windows doesn't care for the name, but Cygwin does, this opens up the
chance to add special handling for the NFSv4 driver to Cygwin.

The first and foremost effect, without *any* changes in Cygwin
necessary, would be that Cygwin handles the NFSv4 driver just like
any other non-NFS driver:

- Flags like FILE_PERSISTENT_ACLS would actually be utilized.

- stat info would be fetched using
  NtQueryInformationFile(FileAllInformation) rather than via the
  NFS-specific NtQueryEaFile("NfsV3Attributes").

- Along the same lines, symlinks won't be recognized by the
  NfsV3Attributes stat info, but by the Windows default way
  of checking for a reparse point of type IO_REPARSE_TAG_SYMLINK
  (or IO_REPARSE_TAG_LX_SYMLINK if NFSv4 supports it).

And repeating myself, maybe in other words, but Cygwin doesn't do
anything magical.  It's just a user-space DLL relying on the same info
the Windows OS gets.  It's just a matter of how to use that info.

So if you get the info through to Windows, there's always a way to get
it through to Cygwin either.  


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: [Ms-nfs41-client-devel] Windows Server NFS, getfact not working on NFS

[Corinna Vinschen via Cygwin]

On Oct 29 13:56, Martin Wege via Cygwin wrote:
> On Sun, Oct 6, 2024 at 8:53 AM Cedric Blancher
>  wrote:
> > Please run winfsinfo on the NFS filesystem:
> > /bin/winfsinfo getvolumeinfo "$(cygpath -w /cygdrive/n/nfsshare1)"
> >
> > Does winfsinfo getvolumeinfo list the FILE_PERSISTENT_ACLS flag in that 
> > output?
> 
> No, FILE_PERSISTENT_ACLS is not in that output.
> 
> Reading 
> https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getvolumeinformationa
> it means that the Windows NFSv4.1 server does not support ACLs?

https://learn.microsoft.com/en-us/answers/questions/1132611/windows-nfs-server-acls


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: /usr/bin/sg in Cygwin?

[Corinna Vinschen via Cygwin]

On Apr 22 07:55, Cedric Blancher via Cygwin wrote:
> On Mon, 22 Apr 2024 at 01:20, Dan Shelton via Cygwin  
> wrote:
> >
> > On Sat, 20 Apr 2024 at 07:39, Brian Inglis via Cygwin  
> > wrote:
> > >
> > > On 2024-04-19 17:47, Dan Shelton via Cygwin wrote:
> > > > On Fri, 23 Feb 2024 at 22:25, Dan Shelton wrote:
> > > >> Is there a package which provides /usr/bin/sg (execute shell commands
> > > >> in a different group)?
> > >
> > > The POSIX standard command is newgrp - install cygwin-doc to see Cygwin 
> > > (and
> > > newlib libc) man pages (and info, html, PDF docs), man-pages-posix to see 
> > > POSIX
> > > man pages, and man-pages-linux if you want to see recent Linux release 
> > > man pages.
> > >
> > > To see possibly relevant commands, run:
> > >
> > > $ apropos -s 1,1p group
> > > chgrp (1)- change group ownership
> > > chgrp (1p)   - change the file group ownership
> > > chown (1)- change file owner and group
> > > g3topbm (1)  - convert a Group 3 fax file into a PBM image
> > > groups (1)   - print the groups a user is in
> > > id (1)   - print real and effective user and group IDs
> > > make (1) - GNU Make utility to maintain groups of programs
> > > make (1p)- maintain, update, and regenerate groups of programs
> > > mkgroup (1)  - Write /etc/group-like output to stdout
> > > newgrp (1)   - change primary group for a command
> > > newgrp (1p)  - change to a new group
> > > pbmtog3 (1)  - convert a PBM image into a Group 3 MH fax file
> >
> > newgrp(1) is USELESS. It only opens an interactive shell, but does not
> > allow the user to execute a non-interactive script with the requested
> > group like bash -c does.
> 
> Linux /usr/bin/sg source is in
> https://github.com/shadow-maint/shadow/blob/master/src/newgrp.c
> So this is just a packaging issue that whoever does the Cygwin newgrp
> package has to package /usr/bin/sg too

newgrp(1) is a Cygwin util from the base package:

  $ cygcheck -f /usr/bin/newgrp
  cygwin-3.6.0-0.109.ga0a25849f9dd

Reason being that the functionality under Windows is pretty limited
compared to "real" POSIX systems...

https://cygwin.com/cygwin-ug-net/newgrp.html

...and fetching the default environment of the user (to implement the
dash option '-') is pretty different from any other known POSIX system,
having to use Windows functions:

  https://cygwin.com/cgit/newlib-cygwin/tree/winsup/utils/newgrp.c

If anybody thinks he or she can provide a useful shadow-utils
package, feel free.  But it might not be worth the effort, probably.


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: /usr/bin/sg in Cygwin?

[Corinna Vinschen via Cygwin]

On Apr 21 21:35, Eliot Moss via Cygwin wrote:
> On 4/21/2024 7:20 PM, Dan Shelton via Cygwin wrote:
> > On Sat, 20 Apr 2024 at 07:39, Brian Inglis via Cygwin  
> > wrote:
> > > 
> > > On 2024-04-19 17:47, Dan Shelton via Cygwin wrote:
> > > > On Fri, 23 Feb 2024 at 22:25, Dan Shelton wrote:
> > > > > Is there a package which provides /usr/bin/sg (execute shell commands
> > > > > in a different group)?
> > > 
> > > The POSIX standard command is newgrp - install cygwin-doc to see Cygwin 
> > > (and
> > > newlib libc) man pages (and info, html, PDF docs), man-pages-posix to see 
> > > POSIX
> > > man pages, and man-pages-linux if you want to see recent Linux release 
> > > man pages.
> > > 
> > > To see possibly relevant commands, run:
> > > 
> > > $ apropos -s 1,1p group
> > > chgrp (1)- change group ownership
> > > chgrp (1p)   - change the file group ownership
> > > chown (1)- change file owner and group
> > > g3topbm (1)  - convert a Group 3 fax file into a PBM image
> > > groups (1)   - print the groups a user is in
> > > id (1)   - print real and effective user and group IDs
> > > make (1) - GNU Make utility to maintain groups of programs
> > > make (1p)- maintain, update, and regenerate groups of programs
> > > mkgroup (1)  - Write /etc/group-like output to stdout
> > > newgrp (1)   - change primary group for a command
> > > newgrp (1p)  - change to a new group
> > > pbmtog3 (1)  - convert a PBM image into a Group 3 MH fax file
> > 
> > newgrp(1) is USELESS. It only opens an interactive shell, but does not
> > allow the user to execute a non-interactive script with the requested
> > group like bash -c does.
> 
> ??
> 
> The man pages has:
> 
>  newgrp [-] [group] [command [args...]]
> 
> which implies to me that you can give a command.
> 
> Did that not work for you?  EM

WJFFM:

  $ id
  uid=1049577(corinna) gid=1049701(vinschen) 
groups=1049701(vinschen),545(Users),14(REMOTE INTERACTIVE 
LOGON),4(INTERACTIVE),11(Authenticated Users),15(This 
Organization),4095(CurrentSession),66048(LOCAL),1049089(Domain 
Users),70145(Authentication authority asserted identity),1049148(Denied RODC 
Password Replication Group),401408(Medium Mandatory Level)
  $ newgrp Users id -g
  545


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: 3.5.x regression: misquoting command line arguments from native processes

[Corinna Vinschen via Cygwin]

Hi David,

On Apr 20 08:43, David Allsopp via Cygwin wrote:
> Hi Corinna,
> 
> > On Apr  9 22:38, Corinna Vinschen via Cygwin wrote:
> > > On Apr  3 16:53, David Allsopp via Cygwin wrote:
> > > > I have what appears to be a regression in Cygwin 3.5.0 which, owing to
> > > > a CI system lagging behind, we've only just discovered.
> > > > [...]
> > > > $ ./t.exe 'C:\Devel\🐫реализация-mingw64\flexdll\flexdll_mingw64.o'
> > > > stat: cannot stat
> > > > '"C:\Devel\'$'\360\237\220\253''реализация-mingw64\flexdll\flexdll_mingw64.o':
> > > > No such file or directory
> > >
> > > Thanks a lot for the STC!
> > >
> > > I think I fixed that for 3.5.4.  I pushed a patch and the test release
> > > cygwin-3.6.0-0.115.g579064bf4d40 is just building and should be ready
> > > for testing in an hour or two.
> > >
> > > Please give it a try.
> >
> > Sorry for nagging, but do you have some feedback, be it bad or good?
> 
> Sorry for having needed nagging! It does indeed fix it, thank you -
> our smoke-test Bactrian camels can be restored 🐫

Great, nice to read this. I'll keep my camel testcase around, just in
case :)


Thanks,
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: 3.5.x regression: misquoting command line arguments from native processes

[Corinna Vinschen via Cygwin]

Hi David,

On Apr  9 22:38, Corinna Vinschen via Cygwin wrote:
> On Apr  3 16:53, David Allsopp via Cygwin wrote:
> > I have what appears to be a regression in Cygwin 3.5.0 which, owing to
> > a CI system lagging behind, we've only just discovered.
> > [...]
> > $ ./t.exe 'C:\Devel\🐫реализация-mingw64\flexdll\flexdll_mingw64.o'
> > stat: cannot stat
> > '"C:\Devel\'$'\360\237\220\253''реализация-mingw64\flexdll\flexdll_mingw64.o':
> > No such file or directory
> 
> Thanks a lot for the STC!
> 
> I think I fixed that for 3.5.4.  I pushed a patch and the test release
> cygwin-3.6.0-0.115.g579064bf4d40 is just building and should be ready
> for testing in an hour or two.
> 
> Please give it a try.

Sorry for nagging, but do you have some feedback, be it bad or good?


Thanks,
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: Win32 FILE_BASIC_INFORMATION.*Time.QuadPart - which value should be used if filesystem does not support it, so Cygwin /usr/bin/stat lists the value as '-'?

[Corinna Vinschen via Cygwin]

On Apr  9 22:30, Brian Inglis via Cygwin wrote:
> On 2024-04-09 15:14, Corinna Vinschen via Cygwin wrote:
> > On Apr  5 04:26, Martin Wege via Cygwin wrote:
> > > On Fri, Apr 5, 2024 at 2:05 AM Martin Wege  
> > > wrote:
> > > > I have problems with debugging, so a quick help would be appreciated,
> > > > as I cannot figure this out after several hours of digging.
> > > > 
> > > > Cygwin /usr/bin/stat returns "Birth: -" for some files. Which value
> > > > must the CreationTime member of FILE_BASIC_INFORMATION have to cause
> > > > /usr/bin/stat ti return "-"? 0, -1, or something else?
> > > 
> > > In a related matter:
> > > The Win32 FILE_BASIC_INFORMATION structure defines four time values:
> > > 
> > > LARGE_INTEGER CreationTime;
> > > LARGE_INTEGER LastAccessTime;
> > > LARGE_INTEGER LastWriteTime;
> > > LARGE_INTEGER ChangeTime;
> > > 
> > > How can a filesystem indicate if it does not support a particular
> > > timestamp, such as ChangeTime? Should ChangeTime.QuadPart then be -1,
> > > -2 or 0, or another value?
> > 
> > I'm not aware of a filesystem not supporting ChangeTime, that is,
> > st_ctime.  Usually only CreationTime (st_birthtime) is missing.
> 
> R/O media like CD/DVD-R or FS w/o write support?

Oh yes, that makes sense, CDFS and the likes of them.

> > I think setting the timestamp to 0 works for indicating that this kind
> > of timestamp is not supported.  Cygwin is handling Windows timestamps
> > this way, but I can't find this in documentation ATM.
> 
> See upthread?:
> 
> Caller or application can set 0 to mean keep/return current value, caller or
> driver can set -1 to mean don't update/return current value:
> 
> https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/ns-wdm-_file_basic_information#remarks

I'm aware of that.  This remarks session is copy/pasted in other MSFT
articles, too.  But it doesn't really answer Martin's question.

It describes what a consumer (application or driver) is supposed to set
the timestamps to when passing timestamps to a filesystem driver via
ZwSetInformationFile (or its friends on the lower OS levels).

It does *not* describe the other direction of the call stack, i. e.,
what a filesystem driver is supposed to set a timestamp to, if its
underlying filesystem doesn't support this kind of timestamp.

And that's the direction Martin is asking about.


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: Win32 FILE_BASIC_INFORMATION.*Time.QuadPart - which value should be used if filesystem does not support it, so Cygwin /usr/bin/stat lists the value as '-'?

[Corinna Vinschen via Cygwin]

On Apr  5 04:26, Martin Wege via Cygwin wrote:
> On Fri, Apr 5, 2024 at 2:05 AM Martin Wege  wrote:
> >
> > Hello,
> >
> > I have problems with debugging, so a quick help would be appreciated,
> > as I cannot figure this out after several hours of digging.
> >
> > Cygwin /usr/bin/stat returns "Birth: -" for some files. Which value
> > must the CreationTime member of FILE_BASIC_INFORMATION have to cause
> > /usr/bin/stat ti return "-"? 0, -1, or something else?
> 
> In a related matter:
> The Win32 FILE_BASIC_INFORMATION structure defines four time values:
> 
> LARGE_INTEGER CreationTime;
> LARGE_INTEGER LastAccessTime;
> LARGE_INTEGER LastWriteTime;
> LARGE_INTEGER ChangeTime;
> 
> How can a filesystem indicate if it does not support a particular
> timestamp, such as ChangeTime? Should ChangeTime.QuadPart then be -1,
> -2 or 0, or another value?

I'm not aware of a filesystem not supporting ChangeTime, that is,
st_ctime.  Usually only CreationTime (st_birthtime) is missing.

I think setting the timestamp to 0 works for indicating that this kind
of timestamp is not supported.  Cygwin is handling Windows timestamps
this way, but I can't find this in documentation ATM.

But the FS driver can also just fill the CreationTime field with the
same value as LastWriteTime or ChangeTime.  MSFT NFS does that.


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: 3.5.x regression: misquoting command line arguments from native processes

[Corinna Vinschen via Cygwin]

Hi David,

On Apr  3 16:53, David Allsopp via Cygwin wrote:
> I have what appears to be a regression in Cygwin 3.5.0 which, owing to
> a CI system lagging behind, we've only just discovered.
> [...]
> $ ./t.exe 'C:\Devel\🐫реализация-mingw64\flexdll\flexdll_mingw64.o'
> stat: cannot stat
> '"C:\Devel\'$'\360\237\220\253''реализация-mingw64\flexdll\flexdll_mingw64.o':
> No such file or directory

Thanks a lot for the STC!

I think I fixed that for 3.5.4.  I pushed a patch and the test release
cygwin-3.6.0-0.115.g579064bf4d40 is just building and should be ready
for testing in an hour or two.

Please give it a try.


Thanks,
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: cygwin 3.5.3-1 : "Device or resource busy" from 'find {pagefile,swapfile}.sys'

[Corinna Vinschen via Cygwin]

Hi Bruce,

On Apr  4 07:22, Bruce Jerrick via Cygwin wrote:
> As of cygwin 3.5.3-1, 'find' reports "Device or resource busy" and
> exits with status 1 on these two files:
> 
>   $ find /cygdrive/c/{pagefile,swapfile}.sys
>   /cygdrive/c/pagefile.sys
>   find: ‘/cygdrive/c/pagefile.sys’: Device or resource busy
>   /cygdrive/c/swapfile.sys
>   find: ‘/cygdrive/c/swapfile.sys’: Device or resource busy
> 
>   $ echo $?
>   1

Thanks for the report.

Should be fixed in cygwin-3.6.0-0.113.g38b513983590, which is
just being built and should be ready in an hour or two.

This will go into 3.5.4, of course.


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: Cygwin&Win32 file prefetch, block sizes?

[Corinna Vinschen via Cygwin]

On Apr  3 10:14, Corinna Vinschen via Cygwin wrote:
>   
> https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/ns-ntddk-_file_fs_sector_size_information
> 
>   If the filesystem is local and SSINFO_FLAGS_NO_SEEK_PENALTY is set, we
>   could stick to 64K.
> 
>   Otherwise the PhysicalBytesPerSectorForPerformance member might be
>   helpful I guess.  Needs checking, of course.

It's not helpful. This is the output for NTFS:
  (gdb) p ffssi
  $5 = {LogicalBytesPerSector = 512, PhysicalBytesPerSectorForAtomicity = 512,
PhysicalBytesPerSectorForPerformance = 512,
FileSystemEffectivePhysicalBytesPerSectorForAtomicity = 512, Flags = 11,
ByteOffsetForSectorAlignment = 0, ByteOffsetForPartitionAlignment = 0}

D'oh

>   If this isn't any good, we can still fallback to
>   FILE_FS_FULL_SIZE_INFORMATION as in fhandler_base::fstatvfs_by_handle,
>   
> https://cygwin.com/cgit/newlib-cygwin/tree/winsup/cygwin/fhandler/disk_file.cc#n661

So ffsi.BytesPerSector * ffsi.SectorsPerAllocationUnit is it then.

But:

> On Apr  3 00:35, Martin Wege via Cygwin wrote:
> > While I can understand the motivation, FAT32 on multi-GB-devices
> > having 64k block size, and Win32 API on Win95/98/ME/Win7 being
> > optimized to that insane block size, it is absolutely WRONG with
> > today's NTFS and even more so with ReFS.

So this has supposedly changed with Win8. Where's that publically
documented?


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: Implementing /bin/ionice, ioprio_set() support with FILE_IO_PRIORITY_HINT_INFO?

[Corinna Vinschen via Cygwin]

On Apr  3 03:51, Martin Wege via Cygwin wrote:
> Hello,
> 
> could Cygwin implement support for /usr/bin/ionice and ioprio_set()
> via FILE_IO_PRIORITY_HINT_INFO?

Not ionice, the tool, but only ioprio_get/ioprio_set, the API.

The problem is the functionality bit allowing to set the priority
in arbitrary processes.

And, as usual, https://cygwin.com/acronyms/#SHTDI

I would again like to stress the fact that we're all volunteers here,
and we're a sadly small bunch of people actually contributing to the
core code.

It's easy to ask for new functionality, but it needs time to implement
stuff and we all have another job keeping the money coming, and that
job takes priority.

We don't want to see stuff like the xz debacle in Cygwin, right?


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: Cygwin&Win32 file prefetch, block sizes?

[Corinna Vinschen via Cygwin]

On Apr  3 00:35, Martin Wege via Cygwin wrote:
> On Tue, Apr 2, 2024 at 3:17 PM Corinna Vinschen via Cygwin
>  wrote:
> >
> > On Apr  2 02:04, Martin Wege via Cygwin wrote:
> > > Hello,
> > >
> > > Is there any document which describes how Cygwin and Win32 file
> > > prefetch and readahead work, and which sizes are used (e.g. always
> > > read one full page even if only 16 bytes are requested?)?
> >
> > I'm not aware of any docs, but again, keep in mind that Cygwin is a
> > usersapce DLL. We basically do what Windows does for low-level file
> > access.
> >
> > > Quick /usr/bin/stat /etc/profile returns "IO Block: 65536". Does that
> > > mean the file's block size is really 64k? Is this info per filesystem,
> > > or hardcoded in Cygwin?
> >
> > Hardcoded in Cygwin since 2017, based on a discussion in terms of
> > file access performance, especially when using stdio.h functions:
> >
> >   https://cygwin.com/cgit/newlib-cygwin/commit/?id=7bef7db5ccd9c
> 
> OUCH.
> 
> While I can understand the motivation, FAT32 on multi-GB-devices
> having 64k block size, and Win32 API on Win95/98/ME/Win7 being
> optimized to that insane block size, it is absolutely WRONG with
> today's NTFS and even more so with ReFS. This only works if you stream
> files, but as soon as you are doing random read/writes the performance
> is terrible due to cache thrashing. That could explain the many
> complaints about Cygwin's IO performance.

The above patch *only* sets stat::st_blksize to 64K. Nothing else
happens!

This usually means that stdio.h functions use this size for their buffer
and readahead.  It doesn't affect direct calls to read(2)/write(2) and
fread(3)/fwrite(3) at all!

> So, what can be done? I'm not a benchmarking guru, so I'd like to
> propose to add a tunable called EXPERIMENTAL_PREFERRED_IO_BLKSIZE to

No.

We have two ways to handle this *iff* there's really a reason to
handle this.

- Either we just lower PREFERRED_IO_BLKSIZE to 4K or 8K, but that's
  kind of bad in terms of pipes, the clipboard, etc.

- So we keep PREFERRED_IO_BLKSIZE at 64K but don't use it for disk
  files.  Rather, we read this info from the filesystem:

  
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/ns-ntddk-_file_fs_sector_size_information

  If the filesystem is local and SSINFO_FLAGS_NO_SEEK_PENALTY is set, we
  could stick to 64K.

  Otherwise the PhysicalBytesPerSectorForPerformance member might be
  helpful I guess.  Needs checking, of course.

  If this isn't any good, we can still fallback to
  FILE_FS_FULL_SIZE_INFORMATION as in fhandler_base::fstatvfs_by_handle,
  
https://cygwin.com/cgit/newlib-cygwin/tree/winsup/cygwin/fhandler/disk_file.cc#n661

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: xargs completely broken under cygwin 3.6.0-0.108.gb7f5a33200a9

[Corinna Vinschen via Cygwin]

On Apr  2 08:38, Bruce Jerrick via Cygwin wrote:
> 'xargs' is back to working with cygwin-3.6.0-0.109.ga0a25849f9dd .
> 
> Thanks for the quick fix!
> -- Bruce

Thanks for the report and testing!


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: Cygwin&Win32 file prefetch, block sizes?

[Corinna Vinschen via Cygwin]

On Apr  2 02:04, Martin Wege via Cygwin wrote:
> Hello,
> 
> Is there any document which describes how Cygwin and Win32 file
> prefetch and readahead work, and which sizes are used (e.g. always
> read one full page even if only 16 bytes are requested?)?

I'm not aware of any docs, but again, keep in mind that Cygwin is a
usersapce DLL. We basically do what Windows does for low-level file
access.

> Quick /usr/bin/stat /etc/profile returns "IO Block: 65536". Does that
> mean the file's block size is really 64k? Is this info per filesystem,
> or hardcoded in Cygwin?

Hardcoded in Cygwin since 2017, based on a discussion in terms of
file access performance, especially when using stdio.h functions:

  https://cygwin.com/cgit/newlib-cygwin/commit/?id=7bef7db5ccd9c

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: xargs completely broken under cygwin 3.6.0-0.108.gb7f5a33200a9

[Corinna Vinschen via Cygwin]

On Apr  2 12:44, Corinna Vinschen via Cygwin wrote:
> On Apr  2 01:42, Bruce Jerrick via Cygwin wrote:
> > I just did binary-search regression tests on the available
> > old test versions, and found this:
> > 
> > OK:  cygwin-3.6.0-0.86.gbfe2790e7bc4.tar.xz
> > BAD: cygwin-3.6.0-0.92.g8bd6ba8f16ec.tar.xz
> 
> Thanks, I found the offending patch, but I have to think about a
> solution.
> 
> Stay tuned,
> Corinna

Just building cygwin-3.6.0-0.109.ga0a25849f9dd, should be up in
an hour or two. Please give it a try.


Thanks,
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: xargs completely broken under cygwin 3.6.0-0.108.gb7f5a33200a9

[Corinna Vinschen via Cygwin]

On Apr  2 01:42, Bruce Jerrick via Cygwin wrote:
> I just did binary-search regression tests on the available
> old test versions, and found this:
> 
> OK:  cygwin-3.6.0-0.86.gbfe2790e7bc4.tar.xz
> BAD: cygwin-3.6.0-0.92.g8bd6ba8f16ec.tar.xz

Thanks, I found the offending patch, but I have to think about a
solution.

Stay tuned,
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: GetVersionEx() depreciated, what should be used instead for Windows 7/8/10?

[Corinna Vinschen via Cygwin]

On Mar 24 15:42, Christian Franke via Cygwin wrote:
> Corinna Vinschen via Cygwin wrote:
> > On Mar 23 10:57, Christian Franke via Cygwin wrote:
> > > On Mar 21 16:15, Corinna Vinschen via Cygwin wrote:
> > > > On Mar 21 09:58, Christian Franke via Cygwin wrote:
> > > > > > > ..
> > > > I just gave it a try on W11. The results are even more funny than I
> > > > anticipated:
> > > > 
> > > > ...
> > > > 
> > > > So, yeah, with your observations especially on older W10 versions and
> > > > with 8.1 doing the same thing, I guess we can safely drop the extra call
> > > > to RtlGetNtVersionNumbers now.
> > > Or:
> > > Keep RtlGetVersionNumbers, compare result with RtlGetVersion and emit 
> > > debug
> > > output if both differ. This would allow to diagnose a possible future
> > > reappearance of the issue.
> > Good idea! Do you want to create a patch?
> > 
> 
> I tried, but without success. Unfortunately debug_printf() does not work
> because wincap.init() is called before get_cygwin_startup_info() which calls
> strace.activate().

small_printf should work, just needs "\r\n" in the Windows console.

But, anyway, nothing speaks aginst just sticking to the current code.
It works and probably continues to work...


Thanks,
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: GetVersionEx() depreciated, what should be used instead for Windows 7/8/10?

[Corinna Vinschen via Cygwin]

On Mar 23 10:57, Christian Franke via Cygwin wrote:
> On Mar 21 16:15, Corinna Vinschen via Cygwin wrote:
> > On Mar 21 09:58, Christian Franke via Cygwin wrote:
> > > > > ..
> > I just gave it a try on W11. The results are even more funny than I
> > anticipated:
> > 
> > ...
> > 
> > So, yeah, with your observations especially on older W10 versions and
> > with 8.1 doing the same thing, I guess we can safely drop the extra call
> > to RtlGetNtVersionNumbers now.
> 
> Or:
> Keep RtlGetVersionNumbers, compare result with RtlGetVersion and emit debug
> output if both differ. This would allow to diagnose a possible future
> reappearance of the issue.

Good idea! Do you want to create a patch?


Thanks,
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: GetVersionEx() depreciated, what should be used instead for Windows 7/8/10?

[Corinna Vinschen via Cygwin]

On Mar 22 18:13, Ray Satiro via Cygwin wrote:
> On 3/21/2024 11:15 AM, Corinna Vinschen via Cygwin wrote:
> >https://cygwin.com/cgit/newlib-cygwin/commit/?id=48511f3d3847c
> 
> The code in that commit doesn't look right. RtlGetNtVersionNumbers is a void
> function

The code doesn't request a return value.

> and the third parameter may not be just the build number.

Fixed a month later:
https://cygwin.com/cgit/newlib-cygwin/commit/?id=63f19278b998b


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

sourceware test, please ignore

[Corinna Vinschen via Cygwin]

someproc 1234 find_fast_cwd: WARNING: Couldn't compute FAST_CWD
pointer.  Please report this problem to the public mailing list
cygwin@cygwin.com


-- 
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: GetVersionEx() depreciated, what should be used instead for Windows 7/8/10?

[Corinna Vinschen via Cygwin]

On Mar 21 09:58, Christian Franke via Cygwin wrote:
> Corinna Vinschen via Cygwin wrote:
> > On Mar 20 12:39, Christian Franke via Cygwin wrote:
> > > Corinna Vinschen via Cygwin wrote:
> > > > You have to create an application with an application manifest not
> > > > supporting your OS.
> > > > 
> > > > For Cygwin apps, this occured when you built, say, an executable under
> > > > Windows 8.1 before Windows 10 support was added to the Cygwin toolchain:
> > > > the manifest linked to the Cygwin executable didn't yet contain a GUID
> > > > entry for Windows 10 support.
> > > > 
> > > > In this case, RtlGetVersion returns an OS version 6.3 even when running
> > > > under the 10.0 kernel.  This behaviour exists back 'til Windows Vista.
> > > Could not reproduce the latter on Win10. I tested with recent Win10 and
> > > Win11 and also found a Win10 1511 (and Slackware 1.1.2, Win3.1, OS/2, ...)
> > > in my VM image museum.
> > > 
> > > Regardless of the exe manifest, RtlGetVersion and RtlGetNtVersionNumbers
> > > return the correct versions:
> > > 10.0.22621 (Win11 22H2)
> > > 10.0.19045 (Win10 22H2)
> > > 10.0.10586 (Win10 1511)
> > > 
> > > Without a manifest, GetVersionEx returns:
> > > 6.2.9200 (Win8)

I just gave it a try on W11. The results are even more funny than I
anticipated:

I created a simple application just calling GetVersionEx, RtlGetVersion
and RtlGetNtVersionNumbers.

Linked with our Cygwin default manifest claiming W10 compatibility, the
result is the expected:

  GetVersionEx  : 10.0.22631
  RtlGetVersion : 10.0.22631
  RtlGetNtVersionNumbers: 10.0.22631

The "Operating system context" in Task Manager is empty.

Next I linked against a Windows 8.1 manifest:

  GetVersionEx  : 6.3.9600
  RtlGetVersion : 10.0.22631
  RtlGetNtVersionNumbers: 10.0.22631

So GetVersionEx reports Windows 8.1, RtlGetVersion/ RtlGetNtVersionNumbers
both report W10.  The "Operating system context" in Task Manager reports

  "Windows 8.1"

No surprise there.

Next I linked against a Windows 7 manifest:

  GetVersionEx  : 6.2.9200
  RtlGetVersion : 10.0.22631
  RtlGetNtVersionNumbers: 10.0.22631

So GetVersionEx reports Windows 8, not Windows 7.

However, the "Operating system context" in Task Manager reports

  "Windows 7"

I also tried this with a Vista manifest:

  GetVersionEx  : 6.2.9200
  RtlGetVersion : 10.0.22631
  RtlGetNtVersionNumbers: 10.0.22631

  "Windows Vista"

So Task Manager reports the right context per the manifest, but
GetVersionEx doesn't go below Windows 8.

Same goes for Windows 10...

  GetVersionEx  : 6.2.9200
  RtlGetVersion : 10.0.19045
  RtlGetNtVersionNumbers: 10.0.19045

  "Windows Vista"

as well as for Windows 8.1:

  GetVersionEx  : 6.2.9200
  RtlGetVersion : 6.3.9600
  RtlGetNtVersionNumbers: 6.3.9600

  "Windows Vista"

So, yeah, with your observations especially on older W10 versions and
with 8.1 doing the same thing, I guess we can safely drop the extra call
to RtlGetNtVersionNumbers now.  After such a long time, I don't know
on which version of Windows we observed the problem.

For those interested in patch forensics, I searched the archives and
came up with two mail threads referring to GetVersionEx and RtlGetVersion:

  https://cygwin.com/pipermail/cygwin/2013-November/211795.html
  https://cygwin.com/pipermail/cygwin/2014-June/215836.html

Unfortunately I found *no* thread talking about RtlGetNtVersionNumbers,
so the only information we have now is the commit message of

  https://cygwin.com/cgit/newlib-cygwin/commit/?id=48511f3d3847c



Thanks,
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: GetVersionEx() depreciated, what should be used instead for Windows 7/8/10?

[Corinna Vinschen via Cygwin]

On Mar 20 12:39, Christian Franke via Cygwin wrote:
> Corinna Vinschen via Cygwin wrote:
> > You have to create an application with an application manifest not
> > supporting your OS.
> > 
> > For Cygwin apps, this occured when you built, say, an executable under
> > Windows 8.1 before Windows 10 support was added to the Cygwin toolchain:
> > the manifest linked to the Cygwin executable didn't yet contain a GUID
> > entry for Windows 10 support.
> > 
> > In this case, RtlGetVersion returns an OS version 6.3 even when running
> > under the 10.0 kernel.  This behaviour exists back 'til Windows Vista.
> 
> Could not reproduce the latter on Win10. I tested with recent Win10 and
> Win11 and also found a Win10 1511 (and Slackware 1.1.2, Win3.1, OS/2, ...)
> in my VM image museum.
> 
> Regardless of the exe manifest, RtlGetVersion and RtlGetNtVersionNumbers
> return the correct versions:
> 10.0.22621 (Win11 22H2)
> 10.0.19045 (Win10 22H2)
> 10.0.10586 (Win10 1511)
> 
> Without a manifest, GetVersionEx returns:
> 6.2.9200 (Win8)

Please check on commit 48511f3d3847c.  It was a real, existing problem
at the time.  I wouldn't have added the RtlGetNtVersionNumbers call
just for fun.


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: GetVersionEx() depreciated, what should be used instead for Windows 7/8/10?

[Corinna Vinschen via Cygwin]

On Mar 19 09:18, Bill Stewart via Cygwin wrote:
> On Tue, Mar 19, 2024 at 9:01 AM Richard Campbell wrote:
> 
> On Tue, Mar 19, 2024 at 9:04 AM Bill Stewart via Cygwin 
> > wrote:
> >
> > > Can you please clarify the circumstances under which the RtlGetVersion
> > > function "may not return the correct values"?
> >
> > "Originally, using RtlGetVersion instead of GetVersionEx was supposed to
> > fix the fact that GetVersionInfo returns the wrong kernel version if the
> > executable has been built with an old manifest (or none at all), starting
> > with Windows 8.1.  Either this never really worked as desired and our
> > testing was flawed, or this has been changed again with Windows 10, so
> > that RtlGetVersion does the kernel faking twist as well.  Since we're
> > only reading the value in the first process in a process tree. the entire
> > process tree is running with a wrong OS version information in that case.
> >
> > Fortunately, the (undocumented) RtlGetNtVersionNumbers function is not
> > affected by this nonsense, so we simply override the OS version info
> > fields with the correct values now."
> >
> > https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=48511f3d3847c35352d09cded56e25f0c1b22bc9
> >
> 
> Interesting. I have not yet been able to find a scenario where the
> RtlGetVersion function gets "manifested" like GetVersionEx.
> 
> I wrote a small Win32 console utility for displaying and testing OS
> information (requires Windows Vista/Server 2008 or later):
> 
> https://github.com/Bill-Stewart/osinfo
> 
> It uses RtlGetVersion, and this function works correctly for me in all
> current Windows versions (Windows 10, Server 2016, Windows 11, Server 2019,
> Server 2022, etc.).
> 
> I'm not sure of the exact scenario that led to the "RtlGetVersion is
> subject to manifesting" conclusion, but I can't reproduce it.

You have to create an application with an application manifest not
supporting your OS.

For Cygwin apps, this occured when you built, say, an executable under
Windows 8.1 before Windows 10 support was added to the Cygwin toolchain:
the manifest linked to the Cygwin executable didn't yet contain a GUID
entry for Windows 10 support.

In this case, RtlGetVersion returns an OS version 6.3 even when running
under the 10.0 kernel.  This behaviour exists back 'til Windows Vista.

Fortunately Microsoft didn't change the required manifest GUID entry
since the introduction of Windows 10.  Even Windows 11 is still using
the same GUID.


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: No Win ACLs for NFS? Re: ACEs and ACLs

[Corinna Vinschen via Cygwin]

On Mar 19 08:55, Cedric Blancher via Cygwin wrote:
> On Mon, 18 Mar 2024 at 15:43, Corinna Vinschen via Cygwin
>  wrote:
> >
> > On Mar 18 08:30, J. Terry Corbet via Cygwin wrote:
> > > Thank you for the greatly needed assistance, but the reference to which 
> > > you
> > > have pointed me says that noacl will be ignored in the case of ntfs file
> > > systems.
> >
> > No, it doesn't say that.  It says
> >
> >   "The flag is ignored on NFS filesystems."
> >   ^^^
> > not NTFS
> 
> Do ACLs work for NFS in Cygwin, or are they turned off for NFS?

NFS uses the unofficial fattr3 interface to fetch real stat(2) info from
the remote FS, see
https://cygwin.com/cgit/newlib-cygwin/tree/winsup/cygwin/local_includes/nfs.h
https://cygwin.com/cgit/newlib-cygwin/tree/winsup/cygwin/nfs.cc#n19

> I'm also asking because the ms-nfs41-client Windows NFSv4.1 driver now
> has ACL support (like the Exceed NFSv4 driver), but it would be
> frustrating if Cygwin just turns this off.

Cygwin "doesn't turn them off".  Cygwin recognizes the filesystem as
being an NFS filesystem and uses special non-Windowsy access methods
provided by the MS_NFS client.

If you want ACL support for the NFSv4 client, I made a couple of
suggestions how to integrate stuff in Cygwin in November:
https://cygwin.com/pipermail/cygwin-developers/2023-November/012692.html


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: ACEs and ACLs

[Corinna Vinschen via Cygwin]

On Mar 18 09:23, J. Terry Corbet via Cygwin wrote:
> 
> Sorry, 84-yr old eyes sometimes don't work as well.  Thanks for confirming
> that  nothing has changed with regards to these matters; clearly it is some
> change in the way Windows 11 tries to cooperate with Windows 10 in the case
> of mapped network drives being using in the file sharing mode wherein remote
> users must have ids and passwords on the target drives -- which they do and
> always have, but the key ACE entry known as NT AUTHORITY\Authenticated Users
> is correctly specified after performing an icacls /reset, but is not longer
> correctly set after editing a file with vim across the network.  I'll keep
> looking and trying to  learn.  Thank you.

Please add the "noacl" flag where you need it and try again.  The result
is using the standard Windows security, so you should see what you
expect in that case.


Thanks,
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: ACEs and ACLs

[Corinna Vinschen via Cygwin]

On Mar 18 08:30, J. Terry Corbet via Cygwin wrote:
> Thank you for the greatly needed assistance, but the reference to which you
> have pointed me says that noacl will be ignored in the case of ntfs file
> systems.

No, it doesn't say that.  It says

  "The flag is ignored on NFS filesystems."
  ^^^
not NTFS

> All of mine are and that has not changed, neither has the default
> entry in fstab, which seems always to have been:
> 
> none /cygdrive cygdrive binary, posix=0, user 0 0

Well, the code in question hasn't changed for years either.


¯\_(ツ)_/¯
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: ACEs and ACLs

[Corinna Vinschen via Cygwin]

On Mar 16 18:05, J. Terry Corbet via Cygwin wrote:
> [...]
> And here is the status that icacls reports back on the original, owning
> workstation
> after having use vim to modify the two files from that remote workstation.
> 
> FileExp.txt NULL SID:(DENY)(Rc,S,REA,WEA,X,DC)
>     NW10\tcorbet:(DENY)(S,RD,WD,AD,REA,WEA,X,DC)
>     NW10\tcorbet:(D,Rc,WDAC,WO,RA,WA)
>     NW10\None:(Rc,S,RA)
>     NT AUTHORITY\Authenticated Users:(RX,W)
>     NT AUTHORITY\SYSTEM:(RX,W)
>     BUILTIN\Administrators:(RX,W)
>     BUILTIN\Users:(RX)
>     Everyone:(Rc,S,RA)
> 
> vimtest.txt NULL SID:(DENY)(Rc,S,WEA,X,DC)
>     NW10\tcorbet:(R,W,D,WDAC,WO)
>     NW10\None:(DENY)(S,X)
>     NT AUTHORITY\Authenticated Users:(DENY)(S,X)
>     NT AUTHORITY\SYSTEM:(DENY)(S,X)
>     BUILTIN\Administrators:(DENY)(S,X)
>     BUILTIN\Users:(DENY)(S,X)
>     NW10\None:(RX)
>     NT AUTHORITY\Authenticated Users:(RX,W)
>     NT AUTHORITY\SYSTEM:(RX,W)
>     BUILTIN\Administrators:(RX,W)
>     BUILTIN\Users:(RX)
>     Everyone:(R)
> 
> If my understanding is correct concerning the precedence handling of an
> ACL with multiple ACEs for the same user/ID, this result from grep
> on the original, owning workstation would not surprise you:
> 
> F:\Dev\cygshoot>grep foo fileexp.txt
> grep: fileexp.txt: Permission denied
> 
> but it blows me completely away.  Clearly I no longer have an environment
> in which I can work on any file from any workstation using any Cygwin
> utilities.
> 
> What have I messed up?

The problem is that your identity is based on the SID of every single
machine, and the machines don't know the SIDs of other machines.  The
default ACL created in Cygwin is emulating POSIX permissions.  This
becomes a problem when sharing files between machines not in the
same Windows domain.

The workaround is not to use POSIX permissions on shares.  Create
matching mount points in /etc/fstab or /etc/fstab.d/ and add the
"noacl" mount flag:

  https://cygwin.com/cygwin-ug-net/using.html#mount-table

Alternatively, you can also just add an fstab entry for the cygdrive
prefix which adds the "noacl" flag, see

  https://cygwin.com/cygwin-ug-net/using.html#cygdrive

but keep in mind that this also affects local paths if you access
them via the cygdrive prefix.


HTH,
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: Additional odd behavior after my upgrade to the latest CYGWIN64 version

[Corinna Vinschen via Cygwin]

On Mar 16 16:49, Michael Goldshteyn via Cygwin wrote:
> Cygwin handles (filename) case insensitivity in a very weird way at the
> Windows command prompt:
> --
> c:\Users\Michael>set CYGWIN=
> 
> c:\Users\Michael>printf "%q " 'a' 'A' "a" "A" a A
> a A a A a A
> 
> REM OK, so far so good, but, now:
> c:\Users\Michael>set CYGWIN=glob:ignorecase
> 
> C:\Users\Michael>printf "%q " 'a' 'A' "a" "A" a A
> a a a a a A
> 
> REM So, if I don't put a command line arg into any sort of quotes, it gets
> lower-cased for cygwin apps (from the Windows command line).
> REM I should also add that there is no file named 'a' or 'A' in the current
> working directory.
> 
> REM This behavior, of course, doesn't happen in Cygwin bash:
> --
> C:\Users\Michael>bash
> Michael@lambda /cygdrive/c/Users/Michael
> $ echo "$CYGWIN"
> glob:ignorecase
> Michael@lambda /cygdrive/c/Users/Michael
> $ printf "%q " 'a' 'A' "a" "A" a A
> a A a A a A
> $ # Output looks correct, quoted or not
> --
> The unsolicited conversion of case for quoted string is very odd, to say
> the least. If you remove the glob:ignorecase from the CYGWIN env var
> definition, use of filenames on Windows with Cygwin tools becomes
> completely case sensitive, which is very undesirable when compared to the
> fact that other Windows tools do not care about file case (i.e., case
> insensitive, but preserving, as MS puts it).

This was an ill-advised optimization attempt in glob.  I revert the
patch and pushed the change(*), so this will be fixed in Cygwin 3.5.2.

For the time being, you can also test this by installing the just
building Cygwin test release 3.6.0-0.85.g89afbb8d8af2, which should
be available in an hour or two.


Thanks,
Corinna


(*) https://cygwin.com/cgit/newlib-cygwin/commit/?id=70375b2205

-- 
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: Request for a rough release timeline for Cygwin 3.5.2

[Corinna Vinschen via Cygwin]

On Mar 11 11:48, Kate Deplaix via Cygwin wrote:
> Hi,
> 
> Sorry to bother you all,
> 
> Following the fixes (thank you so much again) of the two critical
> issues in cygwin 3.5.0/3.5.1
> https://cygwin.com/pipermail/cygwin/2024-February/255561.html , we
> were wondering if cygwin 3.5.2 is likely to be released soon. We would
> be extremely grateful and happy for that.

Probably still this month.


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: ls/stat on OneDrive causes download of files

[Corinna Vinschen via Cygwin]

On Mar  9 15:29, Marcin Wisnicki via Cygwin wrote:
> I did more testing and found out that the problem does not happen in
> cygwin by default because cygwin mounts with acl which doesn't do
> header sniffing while msys uses noacl.
> 
> Testing on an mp4 file in OneDrive, when I use noacl in cygwin it
> triggers the read as well.
> After upgrading to the test version the read is gone and an mp4 file
> is not executable.
> 
> Thank you!

Thanks a lot for testing.  I backported the changes (minus the lsattr(1)/
chattr(1) changes) to the 3.5 branch so it will be in released with
3.5.2 in the next few weeks.


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: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Corinna Vinschen via Cygwin]

On Mar 11 02:28, Dan Shelton via Cygwin wrote:
> On Wed, 6 Mar 2024 at 14:01, Corinna Vinschen via Cygwin
>  wrote:
> > On Mar  5 23:38, Dan Shelton via Cygwin wrote:
> > > Always editing /etc/nsswitch.conf
> > > forth and back is not a elegant solution, aside from race conditions
> > > with other users on a system
> >
> > So, here we go again.
> >
> > - What exactly are you trying to accomplish by enumerating the accounts?
> >   Maybe you won't actually need it for your task at hand.
> 
> We're trying to do several things, including but not limited to:
> - Finding which local groups exist. Part of our customer software
> expects that certain groups exist. Unfortunately the group names vary
> between installations, and sometimes names are prefixed with site
> names. Trying to do all permutations with just getent passwd
> $iteration means too many combinations (>= 400). So just
> enumerating all local groups with getent group would be the way to go.

Then just change /etc/nsswitch.conf to enumerate "local" as well
and be done with it.

You can even go so far as to use the Windows enumerator, i.e.,

  $ net localgroup

and than script it to use its output as input to getent group
for only the groups you really need info for.


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: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Corinna Vinschen via Cygwin]

On Mar  9 16:26, Glenn Strauss via Cygwin wrote:
> On Wed, Mar 06, 2024 at 02:01:06PM +0100, Corinna Vinschen via Cygwin wrote:
> > On Mar  5 23:38, Dan Shelton via Cygwin wrote:
> > > On Sat, 24 Feb 2024 at 14:11, Corinna Vinschen via Cygwin
> > >  wrote:
> > > >
> > > > On Feb 23 22:15, Dan Shelton via Cygwin wrote:
> > > > > HOWEVER, there is another Cygwin bug:
> > > > > "getent group mywingrp1" does not list any group members, even after
> > > > > "net localgroup mywingrp1 mywinuser44 /add", which is a POSIX
> > > > > violation.
> > > >
> > > > Not a bug.  Two problems:
> > > >
> > > > - Getting members of a group can be an extremly costly operation
> > > >   in a domain or, worse, a domain forest, or even worse, if the
> > > >   domain or domain forest is remote.
> > > >
> > > > - Alonmg the same lines, getting members of a group can be extremly
> > > >   costly in big orgs with thousands of users.  Nobody want's to clutter
> > > >   up space with the list of members in the "Domain Users" group.
> > > >
> > > > - Permissions to enumerate members of a group are restricted.
> > > >   By default only admins and group members are allow to enumerate
> > > >   members and this can be restricted further by domain admins.
> > > >
> > > > Therefore we dropped even trying to populate gr_mem, considering
> > > > that even in its original form on Unix systems, it's used only
> > > > to add supplementary groups.  To do this right on Windows is even
> > > > more costly than blindly enumerating.
> > > >
> > > > It's not a bug, it's a feature :)
> > > 
> > > Could you add an option to getent so that the full lookup can be
> > > requested via command line, pls?
> > 
> > That's not possible.  getent just calls getpwent/getgrent.
> > 
> > > Always editing /etc/nsswitch.conf
> > > forth and back is not a elegant solution, aside from race conditions
> > > with other users on a system
> > 
> > So, here we go again.
> > 
> > - What exactly are you trying to accomplish by enumerating the accounts?
> >   Maybe you won't actually need it for your task at hand.
> > 
> > - Why do you have to change nsswitch.conf "back and forth"?
> >   Just change it once and you're done.
> > 
> > 
> > Corinna
> 
> Hello
> > > Dan Shelton - Cluster Specialist Win/Lin/Bsd
> 
> > > Always editing /etc/nsswitch.conf
> > > forth and back is not a elegant solution, aside from race conditions
> > > with other users on a system
> 
> Please check the man page for getent.
> 
> man getent
> getent --help
> 
> You can use -s or --service to override the service used without
> editing nsswitch.conf.  The man page on Linux provides an example
> with a bit more details than the man page for getent under cygwin.
> https://www.man7.org/linux/man-pages/man1/getent.1.html

The -s option is just available for compatibility, but otherwise a no-op
on Cygwin.  The -i option works as upstream, -w is a Cygwin-only option.

The Cygwin getent.1 man page is a bit old, given it's taken from
upstream and just slightly adapted from glibc 2.18.90, a good 10 years
ago.  The upstream man page at the time did not document the options for
some reason.  These days it documents the options, so we could fetch
this and create a new manpage from there.


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: ls/stat on OneDrive causes download of files

[Corinna Vinschen via Cygwin]

On Mar  8 14:56, Corinna Vinschen via Cygwin wrote:
> On Mar  8 08:15, Jeffrey Altman via Cygwin wrote:
> > On 3/8/2024 7:52 AM, Thomas Wolff via Cygwin wrote:
> > > Am 08.03.2024 um 11:37 schrieb Corinna Vinschen via Cygwin:
> > > >    FILE_OPEN_NO_RECALL (0x0040)
> > > > [...]
> > > > This sounds like we could simply add this flag to all NtOpenFile
> > > > used for path conversion or stat-like calls, without having to care
> > > > for any file attributes specificially.
> > > > 
> > > > Does that make sense?
> > > Sounds good, without even studying the other details...
> > > I speculate some more handling would still be needed to avoid executable
> > > detection via magic tags.
> > > 
> > Agreed.   FILE_OPEN_NO_RECALL has been defined for at least a decade but was
> > not documented by Microsoft relatively recently.
> 
> Thanks for the feedback, guys.
> 
> > Another suggestion would be to try opening the file with
> > FILE_READ_ATTRIBUTES instead of GENERIC_READ if the file data is not
> > required.  See
> > 
> > https://github.com/microsoft/BuildXL/commit/4fb8e7ce07d243ccd95de0d66da551538a794493
> 
> Cygwin uses the minimum of required permissions in NtCreateFile/
> NtOpenFile calls anyway.
> 
> I'm just running a test cygwin DLL locally with a lot of added
> FILE_OPEN_NO_RECALL bits and a couple of added attribute checks for
> being offline to allow skipping some code.
> 
> I think I'll push this change in a bit so we get a test release out
> so people using OneDrive can test.

I pushed this change as well as a followup change to make sure we don't
inadvertently recall an offline file.  I also added handling for the
Pinned and Unpinned attributes to chattr(1) and lsattr(1).

The full set of changes can be tested by installing the Cygwin test
release 3.6.0-0.77.g06aa5a751682.

Please give it a try.  If you encounter a situation which still results
in recalling an offline file in a situation which doesn't qualify for
it, please report.  We will have to analyze that situation further
then.


Thanks,
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: ls/stat on OneDrive causes download of files

[Corinna Vinschen via Cygwin]

On Mar  8 08:15, Jeffrey Altman via Cygwin wrote:
> On 3/8/2024 7:52 AM, Thomas Wolff via Cygwin wrote:
> > Am 08.03.2024 um 11:37 schrieb Corinna Vinschen via Cygwin:
> > > Yesterday I stumbled over a certain NtCreateFile flag:
> > > 
> > >    FILE_OPEN_NO_RECALL (0x0040)
> > > 
> > >  Instructs any filters that perform offline storage or
> > > virtualization
> > >  to not recall the contents of the file as a result of this open.
> > > 
> > > MS-CIFS described it like this:
> > > 
> > >    FILE_OPEN_NO_RECALL
> > >    0x0040
> > > 
> > >  In a hierarchical storage management environment, this option
> > >  requests that the file SHOULD NOT be recalled from tertiary storage
> > >  such as tape. A file recall can take up to several minutes in a
> > >  hierarchical storage management environment. The clients can
> > > specify
> > >  this option to avoid such delays.
> > > 
> > > This sounds like we could simply add this flag to all NtOpenFile
> > > used for path conversion or stat-like calls, without having to care
> > > for any file attributes specificially.
> > > 
> > > Does that make sense?
> > Sounds good, without even studying the other details...
> > I speculate some more handling would still be needed to avoid executable
> > detection via magic tags.
> > 
> Agreed.   FILE_OPEN_NO_RECALL has been defined for at least a decade but was
> not documented by Microsoft relatively recently.

Thanks for the feedback, guys.

> Another suggestion would be to try opening the file with
> FILE_READ_ATTRIBUTES instead of GENERIC_READ if the file data is not
> required.  See
> 
> https://github.com/microsoft/BuildXL/commit/4fb8e7ce07d243ccd95de0d66da551538a794493

Cygwin uses the minimum of required permissions in NtCreateFile/
NtOpenFile calls anyway.

I'm just running a test cygwin DLL locally with a lot of added
FILE_OPEN_NO_RECALL bits and a couple of added attribute checks for
being offline to allow skipping some code.

I think I'll push this change in a bit so we get a test release out
so people using OneDrive can test.


Thanks,
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: ls/stat on OneDrive causes download of files

[Corinna Vinschen via Cygwin]

Hi Jeffrey,

On Mar  6 13:55, Jeffrey Altman via Cygwin wrote:
> On 3/6/2024 12:19 PM, Corinna Vinschen via Cygwin wrote:
> > We can add an explicit call to
> > 
> >RtlSetProcessPlaceholderCompatibilityMode (PHCM_EXPOSE_PLACEHOLDERS);
> > [...]
> Files and directories that are placeholders should have either the
> FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS or FILE_ATTRIBUTE_RECALL_ON_OPEN file
> attributes set. When these attributes are set, applications and mini filters
> are advised not to "read" or "open" the files or directories unless they
> absolutely need to because doing so will cause the placeholder to be
> replaced by an object containing the actual data which might take a long
> time to fetch,

Yesterday I stumbled over a certain NtCreateFile flag:

  FILE_OPEN_NO_RECALL (0x0040)

Instructs any filters that perform offline storage or virtualization
to not recall the contents of the file as a result of this open.

MS-CIFS described it like this:

  FILE_OPEN_NO_RECALL
  0x0040

In a hierarchical storage management environment, this option
requests that the file SHOULD NOT be recalled from tertiary storage
such as tape. A file recall can take up to several minutes in a
hierarchical storage management environment. The clients can specify
this option to avoid such delays.

This sounds like we could simply add this flag to all NtOpenFile
used for path conversion or stat-like calls, without having to care
for any file attributes specificially.

Does that make sense?


Thanks,
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: ls/stat on OneDrive causes download of files

[Corinna Vinschen via Cygwin]

Hi Jeffrey,


apart from the attribute stuff...


On Mar  6 13:55, Jeffrey Altman via Cygwin wrote:
> The default ProcessPlaceholderCompaibilityMode is PHCM_EXPOSE_PLACEHOLDERS
> which makes the FILE_ATTRIBUTE flags and reparse tags visible. Microsoft
> maintains a database of processes for which PHCM_DISGUISE_PLACEHOLDER is set
> which hides that information. Its unclear to me that explicitly setting the
> placeholder compatibility mode is useful.

What I see as a problem here is this:

https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-rtlsetprocessplaceholdercompatibilitymode

Quote:

  "Most Windows applications see exposed placeholders by default. For
   
   compatibility reasons, Windows may decide that certain applications
  ^^
   see disguised placeholders by default."

But then again, in other news from Microsoft:

https://learn.microsoft.com/en-us/windows/win32/cfapi/build-a-cloud-file-sync-engine#compatibility-with-applications-that-use-reparse-points

Quote:

  "[...] the cloud files API always hides its reparse points from all
 
   applications except for sync engines and processes whose main image
   ^^^
   resides under %systemroot%. Applications that understand reparse
   ^^^
   points correctly can force the platform to expose cloud files API
   reparse points using RtlSetProcessPlaceholderCompatibilityMode or
   RtlSetThreadProcessPlaceholderCompatibilityMode.

Considering these two statements, it's totally unclear to a process, if
it just defaults to "exposed" or "disguised".

Fortunately we can ask Windows by calling the
RtlQueryProcessPlaceholderCompatibilityMode() function, right?

Lets have a look into the documentation at
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-rtlqueryprocessplaceholdercompatibilitymode

Quote:

  "Return value

  This function returns the process's placeholder compatibily mode
  (PHCM_xxx), or a negative value on error (PCHM_ERROR_xxx). Contains
  one of the following values:

  Compatibility Mode   Value
  PHCM_APPLICATION_DEFAULT   0
  PHCM_DISGUISE_PLACEHOLDER  1
  PHCM_EXPOSE_PLACEHOLDERS   2
  PHCM_MAX   2
  PHCM_ERROR_INVALID_PARAMETER  -1
  PHCM_ERROR_NO_TEB -2"

So I called the function right at the start of the Cygwin DLL, and it
returns the value 0, i. e., PHCM_APPLICATION_DEFAULT.

At this point the process *still* has no idea if placeholders are
exposed or disguised.  What a great API! \o/

So, from the above, and if we really want to be sure that placeholders
will be exposed, I don't see any way around calling
RtlSetProcessPlaceholderCompatibilityMode(PHCM_EXPOSE_PLACEHOLDERS)
explicitely at DLL startup.

What do you think?


Thanks,
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: ls/stat on OneDrive causes download of files

[Corinna Vinschen via Cygwin]

Hi Jeffrey,


looks like writing our mails overlapped:
https://cygwin.com/pipermail/cygwin/2024-March/255622.html

On Mar  6 13:55, Jeffrey Altman via Cygwin wrote:
> On 3/6/2024 12:19 PM, Corinna Vinschen via Cygwin wrote:
> > We can add an explicit call to
> > 
> >RtlSetProcessPlaceholderCompatibilityMode (PHCM_EXPOSE_PLACEHOLDERS);
> > 
> > and we can recognize the IO_REPARSE_TAG_FILE_PLACEHOLDER and
> > IO_REPARSE_TAG_CLOUD_* tags during symlink evaluation, but even then
> > we still have to know what the reparse point buffer actually contains.
> > 
> > Given that the content of reparse points with these reparse tags are
> > undocumented, some people using cloud services should examine these
> > reparse points so we can add some suitable code to Cygwin.
> > 
> > 
> > Corinna
> I'm not an expert in this area by any means but here are my recollections
> from when Microsoft presented in-person on cloud placeholders to filter and
> filesystem developers many years ago.
> 
> Files and directories that are placeholders should have either the
> FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS or FILE_ATTRIBUTE_RECALL_ON_OPEN file
> attributes set. When these attributes are set, applications and mini filters
> are advised not to "read" or "open" the files or directories unless they
> absolutely need to

Per 
https://learn.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants
FILE_ATTRIBUTE_RECALL_ON_OPEN only appears in directory listing
classes, but not in standard FILE_BASIC_INFORMATION and alike.
That's a bit of a problem considering how we check files during
path conversion.

The MSDN article doesn't state the same for
FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS, which is good, I think.

But I'm a bit puzzled then in terms of FILE_ATTRIBUTE_OFFLINE.  Is it
not used for OneDrive files?

> [...]
> I'm not sure that exposing the object as a symlink is a good idea.

Yeah, that's what I realized as well, see my aforementioned mail.

> Perhaps the question that needs to be asked is whether there are opens that
> can be skipped if an object is known to not be locally present (either of
> the FILE_ATTRIBUTE flags are set)?

This may be the way to go, see my mail.  It wouldn't be much of
a problem to check all attribute bits, i.e. FILE_ATTRIBUTE_OFFLINE,
FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS and FILE_ATTRIBUTE_RECALL_ON_OPEN.
Maybe that's what we should do.


Thanks,
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: ls/stat on OneDrive causes download of files

[Corinna Vinschen via Cygwin]

On Mar  6 18:19, Corinna Vinschen via Cygwin wrote:
> On Mar  6 06:54, Brian Inglis via Cygwin wrote:
> > On 2024-03-06 06:28, Corinna Vinschen via Cygwin wrote:
> > > On Mar  6 14:22, Corinna Vinschen via Cygwin wrote:
> > > > Given these placeholder files are actually reparse points of type
> > > > IO_REPARSE_TAG_FILE_PLACEHOLDER, we can handle them as symbolic links.
> > > > 
> > > > However, the structure of the IO_REPARSE_TAG_FILE_PLACEHOLDER reparse
> > > > data buffer is undocumented.  It would be helpful if somebody using
> > > > OneDrive would examine the content of the attached REPARSE_DATA_BUFFER.
> > > > 
> > > > > [2] 
> > > > > https://github.com/msys2/msys2-runtime/blob/msys2-3.4.10/winsup/cygwin/fhandler/disk_file.cc#L548
> > > > 
> > > > The NtReadFile call at this point is not the problem.  It would be
> > > > helpful to point to Cygwin's source instead of MSYS2, btw.
> > > 
> > > Oh, btw., this is from
> > > https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c8e77b37-3909-4fe6-a4ea-2b9d423b1ee4:
> > > 
> > >IO_REPARSE_TAG_FILE_PLACEHOLDER
> > >0x8015
> > > 
> > >  Obsolete.
> > >  -
> > >  Used by Windows Shell for legacy placeholder files in Windows 8.1.
> > >  Server-side interpretation only, not meaningful over the wire.
> > > 
> > > So even if we support them, what is their replacement in W10 and later?
> > 
> > May or not help:
> > 
> > https://stackoverflow.com/questions/59152220/cant-get-reparse-point-information-for-the-onedrive-folder
> 
> We can add an explicit call to
> 
>   RtlSetProcessPlaceholderCompatibilityMode (PHCM_EXPOSE_PLACEHOLDERS);
> 
> and we can recognize the IO_REPARSE_TAG_FILE_PLACEHOLDER and
> IO_REPARSE_TAG_CLOUD_* tags during symlink evaluation, but even then
> we still have to know what the reparse point buffer actually contains.
> 
> Given that the content of reparse points with these reparse tags are
> undocumented, some people using cloud services should examine these
> reparse points so we can add some suitable code to Cygwin.

Reading further on this it seems that one cannot easily compare these
reparse points with symlinks.

The tag values are 0x8015 for IO_REPARSE_TAG_FILE_PLACEHOLDER and
0x901AL up to 0x9000F01AL for the IO_REPARSE_TAG_CLOUD_* tags.  None
of them have the name surrogate bit set, so they don't "represent
another named entity in the system".  In other words, these reparse
points represent themselves rather than pointing to some other file, as
symlinks do.

Additionally the IO_REPARSE_TAG_CLOUD_* tags all have the directory bit
set so it seems they are used on the parent(?) directory of the local
OneDrive copy only, but not on the files inside it.

Bottom line:

I wonder if the real deal is not the reparse tag and the reparse
content, but whether or not the file has the FILE_ATTRIBUTE_OFFLINE flag
set.

If so, we can try to disable any action within path conversion, as 
well as in our stat(2) and readdir(3) implementation which would
trigger onlining an offline file.

Can anybody confirm that the idea is right, or if I'm something missing?


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: ls/stat on OneDrive causes download of files

[Corinna Vinschen via Cygwin]

On Mar  6 06:54, Brian Inglis via Cygwin wrote:
> On 2024-03-06 06:28, Corinna Vinschen via Cygwin wrote:
> > On Mar  6 14:22, Corinna Vinschen via Cygwin wrote:
> > > Given these placeholder files are actually reparse points of type
> > > IO_REPARSE_TAG_FILE_PLACEHOLDER, we can handle them as symbolic links.
> > > 
> > > However, the structure of the IO_REPARSE_TAG_FILE_PLACEHOLDER reparse
> > > data buffer is undocumented.  It would be helpful if somebody using
> > > OneDrive would examine the content of the attached REPARSE_DATA_BUFFER.
> > > 
> > > > [2] 
> > > > https://github.com/msys2/msys2-runtime/blob/msys2-3.4.10/winsup/cygwin/fhandler/disk_file.cc#L548
> > > 
> > > The NtReadFile call at this point is not the problem.  It would be
> > > helpful to point to Cygwin's source instead of MSYS2, btw.
> > 
> > Oh, btw., this is from
> > https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c8e77b37-3909-4fe6-a4ea-2b9d423b1ee4:
> > 
> >IO_REPARSE_TAG_FILE_PLACEHOLDER
> >0x8015
> > 
> >  Obsolete.
> >  -
> >  Used by Windows Shell for legacy placeholder files in Windows 8.1.
> >  Server-side interpretation only, not meaningful over the wire.
> > 
> > So even if we support them, what is their replacement in W10 and later?
> 
> May or not help:
> 
> https://stackoverflow.com/questions/59152220/cant-get-reparse-point-information-for-the-onedrive-folder

We can add an explicit call to

  RtlSetProcessPlaceholderCompatibilityMode (PHCM_EXPOSE_PLACEHOLDERS);

and we can recognize the IO_REPARSE_TAG_FILE_PLACEHOLDER and
IO_REPARSE_TAG_CLOUD_* tags during symlink evaluation, but even then
we still have to know what the reparse point buffer actually contains.

Given that the content of reparse points with these reparse tags are
undocumented, some people using cloud services should examine these
reparse points so we can add some suitable code to 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: ls/stat on OneDrive causes download of files

[Corinna Vinschen via Cygwin]

On Mar  6 14:22, Corinna Vinschen via Cygwin wrote:
> On Mar  5 19:54, Marcin Wisnicki via Cygwin wrote:
> > If I invoke ls or anything else that does stat inside OneDrive folder
> > it will trigger download of all files.
> > 
> > OneDrive uses placeholder files[1] to represent remote files.
> > 
> > I'm guessing reading file content in stat is to support detection of
> > actually executable files as in here[2]?
> > 
> > I think this should be disabled on non-hydrated placeholder files.
> > Running `find` or 'ls -R` and having your entire OneDrive downloaded
> > is extremely problematic.
> > 
> > I could live without executable scripts in the OneDrive folder and
> > it's easy to mark files as always offline to solve it.
> > 
> > Another idea is to skip checking files with extensions known to be
> > non-executable such as jpg (or just any extensions that is not known
> > to be executable).
> 
> Nothing of this makes sense from a POSIX library POV.  The library can
> either not handle placeholder files specially, as today, or it can
> handle them all the same way.
> 
> Given these placeholder files are actually reparse points of type
> IO_REPARSE_TAG_FILE_PLACEHOLDER, we can handle them as symbolic links.
> 
> However, the structure of the IO_REPARSE_TAG_FILE_PLACEHOLDER reparse
> data buffer is undocumented.  It would be helpful if somebody using
> OneDrive would examine the content of the attached REPARSE_DATA_BUFFER.
> 
> > [2] 
> > https://github.com/msys2/msys2-runtime/blob/msys2-3.4.10/winsup/cygwin/fhandler/disk_file.cc#L548
> 
> The NtReadFile call at this point is not the problem.  It would be
> helpful to point to Cygwin's source instead of MSYS2, btw.

Oh, btw., this is from
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c8e77b37-3909-4fe6-a4ea-2b9d423b1ee4:

  IO_REPARSE_TAG_FILE_PLACEHOLDER
  0x8015

Obsolete.
-
Used by Windows Shell for legacy placeholder files in Windows 8.1.
Server-side interpretation only, not meaningful over the wire.

So even if we support them, what is their replacement in W10 and later?


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: ls/stat on OneDrive causes download of files

[Corinna Vinschen via Cygwin]

On Mar  5 19:54, Marcin Wisnicki via Cygwin wrote:
> If I invoke ls or anything else that does stat inside OneDrive folder
> it will trigger download of all files.
> 
> OneDrive uses placeholder files[1] to represent remote files.
> 
> I'm guessing reading file content in stat is to support detection of
> actually executable files as in here[2]?
> 
> I think this should be disabled on non-hydrated placeholder files.
> Running `find` or 'ls -R` and having your entire OneDrive downloaded
> is extremely problematic.
> 
> I could live without executable scripts in the OneDrive folder and
> it's easy to mark files as always offline to solve it.
> 
> Another idea is to skip checking files with extensions known to be
> non-executable such as jpg (or just any extensions that is not known
> to be executable).

Nothing of this makes sense from a POSIX library POV.  The library can
either not handle placeholder files specially, as today, or it can
handle them all the same way.

Given these placeholder files are actually reparse points of type
IO_REPARSE_TAG_FILE_PLACEHOLDER, we can handle them as symbolic links.

However, the structure of the IO_REPARSE_TAG_FILE_PLACEHOLDER reparse
data buffer is undocumented.  It would be helpful if somebody using
OneDrive would examine the content of the attached REPARSE_DATA_BUFFER.

> [2] 
> https://github.com/msys2/msys2-runtime/blob/msys2-3.4.10/winsup/cygwin/fhandler/disk_file.cc#L548

The NtReadFile call at this point is not the problem.  It would be
helpful to point to Cygwin's source instead of MSYS2, btw.


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: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Corinna Vinschen via Cygwin]

On Mar  5 23:38, Dan Shelton via Cygwin wrote:
> On Sat, 24 Feb 2024 at 14:11, Corinna Vinschen via Cygwin
>  wrote:
> >
> > On Feb 23 22:15, Dan Shelton via Cygwin wrote:
> > > HOWEVER, there is another Cygwin bug:
> > > "getent group mywingrp1" does not list any group members, even after
> > > "net localgroup mywingrp1 mywinuser44 /add", which is a POSIX
> > > violation.
> >
> > Not a bug.  Two problems:
> >
> > - Getting members of a group can be an extremly costly operation
> >   in a domain or, worse, a domain forest, or even worse, if the
> >   domain or domain forest is remote.
> >
> > - Alonmg the same lines, getting members of a group can be extremly
> >   costly in big orgs with thousands of users.  Nobody want's to clutter
> >   up space with the list of members in the "Domain Users" group.
> >
> > - Permissions to enumerate members of a group are restricted.
> >   By default only admins and group members are allow to enumerate
> >   members and this can be restricted further by domain admins.
> >
> > Therefore we dropped even trying to populate gr_mem, considering
> > that even in its original form on Unix systems, it's used only
> > to add supplementary groups.  To do this right on Windows is even
> > more costly than blindly enumerating.
> >
> > It's not a bug, it's a feature :)
> 
> Could you add an option to getent so that the full lookup can be
> requested via command line, pls?

That's not possible.  getent just calls getpwent/getgrent.

> Always editing /etc/nsswitch.conf
> forth and back is not a elegant solution, aside from race conditions
> with other users on a system

So, here we go again.

- What exactly are you trying to accomplish by enumerating the accounts?
  Maybe you won't actually need it for your task at hand.

- Why do you have to change nsswitch.conf "back and forth"?
  Just change it once and you're done.


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: UNIX nobody/nogroup mapping to which Windows SID/account?

[Corinna Vinschen via Cygwin]

On Mar  3 14:45, Martin Wege via Cygwin wrote:
> Hello,
> 
> How can we map UNIX "nobody"/"nogroup" to Win32 SIDs/accounts? Cygwin
> has entries for "nobody" in /etc/passwd and "nogroup" in /etc/group,
> but these accounts have SIDs returned by /usr/bin/getent passwd and
> /usr/bin/getent group which LookupAccountSidA() does not recognise.
> 
> So what is the correct Win32 solution?

I urge you to read the entire thread starting at

https://sourceware.org/legacy-ml/cygwin/2016-06/msg00347.html

There's a *LOT* of information in there in terms of discussing and
creating the nobody/nogroup mapping.

Bottom line is, there's no nobody account equivalent on Windows and no
resolvable SID/Name pair.  Thus, we decided to use the SID S-1-0-65534
mapped to uid/gid 65534 for this purpose.  This doesn't matter to native
Windows, it's just some foreign SID.  But it's resolvable inside Cygwin:

  $ getent passwd S-1-0-65534
  no+body:*:65534:65534:U-no\body,S-1-0-65534:/:/sbin/nologin
  $  getent group S-1-0-65534
  no+body:S-1-0-65534:65534:


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: openat(O_DIRECT) supported in Cygwin?

[Corinna Vinschen via Cygwin]

On Feb 27 17:46, Martin Wege via Cygwin wrote:
> Hello,
> 
> Does Cygwin support openat(O_DIRECT)? Which effect does O_DIRECT in
> Cygwin have, and which underlying Windows API is used?

https://cygwin.com/cgit/newlib-cygwin/tree/winsup/cygwin/fhandler/base.cc#n587


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: How can I get the group SID for a file in cmd.exe (powershell is not an option)?

[Corinna Vinschen via Cygwin]

On Feb 27 15:41, Cedric Blancher via Cygwin wrote:
> Good afternoon!
> 
> How can I get the group SID for a file in cmd.exe (powershell is not an 
> option)?
> Is it possible to add an option to ls -l to list the user/group SIDs too?

No, but you can use Cygwin tools:

 getent -w group $(ls -gn foo | awk '{print $3}') | awk -F: '{print $4}'


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: passwd/group/grent fixes for Cygwin 3.5.1?

[Corinna Vinschen via Cygwin]

On Feb 27 04:21, Dan Shelton via Cygwin wrote:
> On Mon, 26 Feb 2024 at 10:18, Corinna Vinschen via Cygwin
>  wrote:
> >
> > On Feb 26 04:44, Dan Shelton via Cygwin wrote:
> > > Hello!
> > >
> > > Can these 3 commits please be backported to the Cygwin 3.5.1 branch?
> > >
> > > 4 days agoCorinna VinschenCygwin: getgrent/getpwent: avoid local
> > > enumeration...commit | commitdiff | tree
> > > 4 days agoCorinna VinschenCygwin: getgrent: fix local SAM enumeration
> > > on domain...commit | commitdiff | tree
> > > 5 days agoCorinna VinschenCygwin: passwd/group: drop Capability
> > > SIDscommit | commitdiff | tree
> >
> > Did changing db_enum in /etc/nsswitch.conf help on your test machine?
> 
> Yes, just adding "local" to db_enum worked, but it is not much of a

Thanks, good to know.

> solution since I need Administrator rights on the target machine,
> which is not going to happen.

If you're not admin, why do you have to enumerate accounts?  This
is usually not an action required by standard applications.

> Why are local groups excluded by default?

Because enumerating local group means to enumerate the entire AD
group list on DCs, which is not feasible in some scenarios.  And
there is a way to configure this by changing /etc/nsswitch.conf.
If you need this on machines you're not admin of, why not just
ask the admin to enable this?


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: cygwin1.dll 3.5.0-1 appears to cause spurious "error 127" with make 4.4.1

[Corinna Vinschen via Cygwin]

On Feb 26 20:08, Dimitry Andric via Cygwin wrote:
> On 26 Feb 2024, at 20:03, Corinna Vinschen  wrote:
> > 
> > On Feb 26 17:34, Dimitry Andric via Cygwin wrote:
> >> Hi,
> >> 
> >> After a recent upgrade of a Cygwin installation, including cygwin1.dll
> >> (see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to
> >> 3.5.0-1, I now get spurious "error 127" messages from (Cygwin's copy of)
> >> GNU make 4.4.1-2, when it starts external processes and those external
> >> processes exit with a zero exit code.
> >> 
> >> For example, a very simple Makefile:
> >> 
> >> all:
> >> cmd /c echo done
> >> 
> >> Running this a few times in a Cygwin bash prompt, gives:
> >> [...]
> >>  make: *** [Makefile:2: all] Error 127
> > 
> > This is probably what has been fixed for 3.5.1 already in patch
> > aa73e1152426 ("Cygwin: console: Fix exit code for non-cygwin process.")
> > 
> > For testing, please install the most recent test release
> > cygwin-3.6.0-0.62.gc2f6c0415501 via the Cygwin installer and try again.
> 
> Yes, I tried that and it fixes it, thanks!

Great, thanks for your feedback!


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: cygwin1.dll 3.5.0-1 appears to cause spurious "error 127" with make 4.4.1

[Corinna Vinschen via Cygwin]

On Feb 26 17:34, Dimitry Andric via Cygwin wrote:
> Hi,
> 
> After a recent upgrade of a Cygwin installation, including cygwin1.dll
> (see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to
> 3.5.0-1, I now get spurious "error 127" messages from (Cygwin's copy of)
> GNU make 4.4.1-2, when it starts external processes and those external
> processes exit with a zero exit code.
> 
> For example, a very simple Makefile:
> 
> all:
>   cmd /c echo done
> 
> Running this a few times in a Cygwin bash prompt, gives:
> [...]
>   make: *** [Makefile:2: all] Error 127

This is probably what has been fixed for 3.5.1 already in patch
aa73e1152426 ("Cygwin: console: Fix exit code for non-cygwin process.")

For testing, please install the most recent test release
cygwin-3.6.0-0.62.gc2f6c0415501 via the Cygwin installer and try again.


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: Will all SIDs fit into |SECURITY_MAX_SID_SIZE| bytes ? / was: Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Corinna Vinschen via Cygwin]

On Feb 25 22:04, Roland Mainz via Cygwin wrote:
> On Sat, Feb 24, 2024 at 7:57 PM Corinna Vinschen via Cygwin
>  wrote:
> >
> > On Feb 24 15:38, Roland Mainz via Cygwin wrote:
> > > On Thu, Feb 22, 2024 at 8:11 PM Corinna Vinschen via Cygwin
> > >  wrote:
> > > > On Feb 22 18:38, Roland Mainz via Cygwin wrote:
> > > > > If I switch the current user's group with /usr/bin/newgrp, how can a
> > > > > (native) Win32 process use
> > > > > |GetTokenInformation(GetCurrentThreadToken(), ...)| to find out which
> > > > > group is the new "current group" (e.g. which |TokenInformationClass|
> > > > > should I use) ?
> > > >
> > > >   PSID sidbuf = (PSID) alloca (SECURITY_MAX_SID_SIZE);
> > > [snip]
> > >
> > > Win32/NT API question: All known SIDs will fit into
> > > |SECURITY_MAX_SID_SIZE| bytes, right ? I'm asking because right now
> > > the ms-nfs41-client code assumes that all SIDs use a variable amount
> > > of memory, and we always have to ask the Win32/NT API about the number
> > > of bytes to allocate. If |SECURITY_MAX_SID_SIZE| is the global maximum
> > > limit for all Windows versions, then we could simplify the code a
> > > lot...
> >
> > Yes.  ACLs are size restricted to 64K, though, but that shouldn't be
> > much of a problem usally.
> 
> Erm... why ACLs? I was asking about the memory allocation size for an SID.

I know, and I wrote "Yes".

I mentioned ACLs because ACLs consist of SIDs and if all SIDs take
SECURITY_MAX_SID_SIZE bytes... well, no worries.


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: passwd/group/grent fixes for Cygwin 3.5.1?

[Corinna Vinschen via Cygwin]

On Feb 26 04:44, Dan Shelton via Cygwin wrote:
> Hello!
> 
> Can these 3 commits please be backported to the Cygwin 3.5.1 branch?
> 
> 4 days agoCorinna VinschenCygwin: getgrent/getpwent: avoid local
> enumeration...commit | commitdiff | tree
> 4 days agoCorinna VinschenCygwin: getgrent: fix local SAM enumeration
> on domain...commit | commitdiff | tree
> 5 days agoCorinna VinschenCygwin: passwd/group: drop Capability
> SIDscommit | commitdiff | tree

Did changing db_enum in /etc/nsswitch.conf help on your test machine?

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: Will all SIDs fit into |SECURITY_MAX_SID_SIZE| bytes ? / was: Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Corinna Vinschen via Cygwin]

On Feb 24 15:38, Roland Mainz via Cygwin wrote:
> On Thu, Feb 22, 2024 at 8:11 PM Corinna Vinschen via Cygwin
>  wrote:
> > On Feb 22 18:38, Roland Mainz via Cygwin wrote:
> > > If I switch the current user's group with /usr/bin/newgrp, how can a
> > > (native) Win32 process use
> > > |GetTokenInformation(GetCurrentThreadToken(), ...)| to find out which
> > > group is the new "current group" (e.g. which |TokenInformationClass|
> > > should I use) ?
> >
> >   PSID sidbuf = (PSID) alloca (SECURITY_MAX_SID_SIZE);
> [snip]
> 
> Win32/NT API question: All known SIDs will fit into
> |SECURITY_MAX_SID_SIZE| bytes, right ? I'm asking because right now
> the ms-nfs41-client code assumes that all SIDs use a variable amount
> of memory, and we always have to ask the Win32/NT API about the number
> of bytes to allocate. If |SECURITY_MAX_SID_SIZE| is the global maximum
> limit for all Windows versions, then we could simplify the code a
> lot...

Yes.  ACLs are size restricted to 64K, though, but that shouldn't be
much of a problem usally.


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: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Corinna Vinschen via Cygwin]

On Feb 23 22:15, Dan Shelton via Cygwin wrote:
> HOWEVER, there is another Cygwin bug:
> "getent group mywingrp1" does not list any group members, even after
> "net localgroup mywingrp1 mywinuser44 /add", which is a POSIX
> violation.

Not a bug.  Two problems:

- Getting members of a group can be an extremly costly operation
  in a domain or, worse, a domain forest, or even worse, if the 
  domain or domain forest is remote.

- Alonmg the same lines, getting members of a group can be extremly
  costly in big orgs with thousands of users.  Nobody want's to clutter
  up space with the list of members in the "Domain Users" group.

- Permissions to enumerate members of a group are restricted.
  By default only admins and group members are allow to enumerate
  members and this can be restricted further by domain admins.

Therefore we dropped even trying to populate gr_mem, considering
that even in its original form on Unix systems, it's used only
to add supplementary groups.  To do this right on Windows is even
more costly than blindly enumerating.

It's not a bug, it's a feature :)


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: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Corinna Vinschen via Cygwin]

On Feb 23 19:45, Roland Mainz via Cygwin wrote:
> On Fri, Feb 23, 2024 at 4:47 PM Corinna Vinschen via Cygwin
>  wrote:
> > On Feb 23 14:03, Roland Mainz via Cygwin wrote:
> > > Do you have any idea what is going wrong in this case ?
> >
> > Not sure about that.  I'm not familiar with driver development under
> > Windows.
> 
> Me neither, I'm still new to this whole Windows kernel stuff (coming
> from SUN&Solaris engineering), but as we need a NFSv4 filesystem
> client at work I'm basically forced at knifepoint to learn as fast as
> I can... ;-/
> 
> > I'd expect that you get the token of the calling thread or, in
> > this case, process as is.
> 
> I think it's the calling thread which makes the Win32 syscall, then
> the MiniRedirector driver (nfs41_driver.sys) gets that security
> context, and uses that to set the impersonation stuff when making the
> upcall to the userland part (nfsd_debug.exe), so that daemon thread
> can impersonate the caller.
> 
> > However, did you try this with a primary group SID being part of the
> > token's supplementary group list, or did you try this with some
> > arbitrary group SID?
> 
> I tried it like this:
> 1. On the Windows machine I created these two new groups:
>  snip 
> WINHOST1:~$ net localgroup cygwingrp1 /add
> WINHOST1:~$ net localgroup cygwingrp2 /add
> WINHOST1:~$ getent group cygwingrp1
> cygwingrp1:S-1-5-21-3286904461-66123-4220857270-1003:197611:
> WINHOST1:~$ getent group cygwingrp2
> cygwingrp2:S-1-5-21-3286904461-66123-4220857270-1004:197612:
>  snip 
> 
> On the Linux NFSv4 server side I added these groups too, and added
> group membership for the matching user:
>  snip 
> root@DERFWNB4966:~# groupadd -g 197611 cygwingrp1
> root@DERFWNB4966:~# groupadd -g 197612 cygwingrp2
> root@DERFWNB4966:~# usermod -a -G cygwingrp1 roland_mainz
> root@DERFWNB4966:~# usermod -a -G cygwingrp2 roland_mainz
>  snip 
> 
> After that /usr/bin/chgrp on Cygwin works on the NFSv4.1 filesystem,
> but if I do a /usr/bin/newgrp+/usr/bin/touch it will not create files
> with that new group, because nfsd_debug.exe only sees the default
> primary group, not the new primary group set by /usr/bin/newgrp.
> 
> Or is there a mistake - do I have to add the current user to the
> Windows localgroup first somehow (like usermod on Linux) ?

Yes, there's a mistake, but in some way it's not your fault.

You have to make sure that the user calling newgrp is member in the
group *and* it has to be in the current user token's TOKEN_GROUP list.

The fact that it (looks like it) works on Cygwin does not mean it
actually worked on the OS level.  See below.

> > I toyed around a bit with this in user space, and it seems I
> > misinterpreted the results when I added the newgrp(1) tool.  The primary
> > group in the token *must* be member of the token's supplementary group
> > list.
> 
> Like on UNIX, right ?

No.  On UNIX it depends if you're a privileged process with the
CAP_SETGID capability.  If so, you can set the pgrp to any arbitrary
group without being asked for credentials.  If you're non-priv'ed,
you can change to any group from the supplementary group list without
being asked for credentials, *or* you're asked for credentials (group
password).

> > The fact that it looks like it works in Cygwin to set the pgrp to
> > an arbitrary SID is apparently based on incorrect error handling.
> >
> > I will fix this in the next couple of days.
> 
> Thanks :-)

In fact I can't fix it and here's why:

Windows only allows to set the new primary group to a group which is
already in the TOKEN_GROUP list of the manipulated user token.  Even
a privileged account can't do that.  Only creating a new token from
scratch will do this.

However, there's a problem.  Consider the OpenSSH server sshd.  It
switches the user account basically like this:

  if (setgid(newgid) != 0)
ERROR;
  if (setuid(newuid) !=0)
ERROR;

Only after the setuid(2) call, Cygwin has full information to create the
new token for the process of the user just logging in.  So during the
setgid(2) call, Cygwin can only operate on the token of the service
account running sshd.

Now, if setgid(2) would fail if the group is not in the user token
of the current effective account, sshd would practically always fail.

So what Cygwin does is to fake success in setgid(2) even if switching
the pgrp in the token failed.  It just stores the information in its
internal user account representation.  Then, when setuid(2) gets called,
it will try to rectify this in the new user's token.

That's why setgid(2) always succeeds if the group exists.  We just don&

Re: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Corinna Vinschen via Cygwin]

On Feb 23 14:03, Roland Mainz via Cygwin wrote:
> On Thu, Feb 22, 2024 at 8:11 PM Corinna Vinschen via Cygwin
>  wrote:
> > On Feb 22 18:38, Roland Mainz via Cygwin wrote:
> > > If I switch the current user's group with /usr/bin/newgrp, how can a
> > > (native) Win32 process use
> > > |GetTokenInformation(GetCurrentThreadToken(), ...)| to find out which
> > > group is the new "current group" (e.g. which |TokenInformationClass|
> > > should I use) ?
> >
> >   PSID sidbuf = (PSID) alloca (SECURITY_MAX_SID_SIZE);
> >   NTSTATUS status;
> >   ULONG size;
> >
> >   status = NtQueryInformationToken (hProcToken, TokenPrimaryGroup,
> > sidbuf, SECURITY_MAX_SID_SIZE,
> > &size);
> 
> Well, it works in the case of an "hello world" application, but if I
> stuff that into the nfsd_daemon (NFSv4.1 ms-nfs41-client client
> daemon) it always prints the default primary group, even if the
> current thread should impersonate another user - or in this case even
> the same user, but a different primary group (e.g. see
> https://github.com/kofemann/ms-nfs41-client/blob/master/sys/nfs41_driver.c#L1367).
> 
> Do you have any idea what is going wrong in this case ?

Not sure about that.  I'm not familiar with driver development under
Windows.  I'd expect that you get the token of the calling thread or, in
this case, process as is.

However, did you try this with a primary group SID being part of the
token's supplementary group list, or did you try this with some
arbitrary group SID?

I toyed around a bit with this in user space, and it seems I
misinterpreted the results when I added the newgrp(1) tool.  The primary
group in the token *must* be member of the token's supplementary group
list.

The fact that it looks like it works in Cygwin to set the pgrp to
an arbitrary SID is apparently based on incorrect error handling.

I will fix this in the next couple of days.


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: BUG: Cygwin getent group refuses to list group added with net localgroup mygrp1 /add

[Corinna Vinschen via Cygwin]

On Feb 23 09:10, Dan Shelton via Cygwin wrote:
> On Tue, 20 Feb 2024 at 21:45, Corinna Vinschen via Cygwin
>  wrote:
> >
> > On Feb 20 17:24, Dan Shelton via Cygwin wrote:
> > > On Tue, 20 Feb 2024 at 10:57, Corinna Vinschen via Cygwin
> > >  wrote:
> > > >
> > > > On Feb 20 05:13, Dan Shelton via Cygwin wrote:
> > > > > Hello!
> > > > >
> > > > > I think I found a rather nasty bug:
> > > > > 1. Add a new group with "net localgroup mygrp1 /add"
> > > > > 2. Then list all groups with "getent group", the new group mygrp1 will
> > > > > not show up. "getent group mygrp1" will list it, but this is useless
> > > > > in my case, as I need the group listed by "getent group"
> > > >
> > > > I guess we can rule out a domain controller but is this a standalone
> > > > machine or a domain member machine?
> > >
> > > Standalone test machine, stock Windows 10 installed 2 days ago,
> > > current patches, Cygwin 3.5 from 2 days ago.
> > >
> > > >
> > > > What's the setting of your /etc/nsswitch.conf?
> > >
> > > Only comments in that file, i.e. empty
> >
> > Please set the db_enum: line to
> >
> >   db_enum: all
> >
> > and try again after exiting from the shell window.  Have a look at
> > https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch
> > for the settings.  By default account enumeration only returns
> > the bare minimum for speed.
> >
> > Btw, there *is* a bug in that code, but it affects only domain
> > menber machines, afaics.
> 
> I saw you did a couple of commits related to "getent group". Is any of
> these commits fixing the problem that a new Win32 local group created
> with "net localgroup mygrp1 /add"  does not show up in the output of
> "getent group"?

Did you read my previous reply and tried what I wrote?


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: Switching groups with newgrp - how to get the new group with |GetTokenInformation()| ?

[Corinna Vinschen via Cygwin]

On Feb 22 18:38, Roland Mainz via Cygwin wrote:
> Hi!
> 
> 
> 
> If I switch the current user's group with /usr/bin/newgrp, how can a
> (native) Win32 process use
> |GetTokenInformation(GetCurrentThreadToken(), ...)| to find out which
> group is the new "current group" (e.g. which |TokenInformationClass|
> should I use) ?

  PSID sidbuf = (PSID) alloca (SECURITY_MAX_SID_SIZE);
  NTSTATUS status;
  ULONG size;

  status = NtQueryInformationToken (hProcToken, TokenPrimaryGroup,
sidbuf, SECURITY_MAX_SID_SIZE,
&size);


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: binutils >= 2.41 makes .rsrc section read-only

[Corinna Vinschen via Cygwin]

On Feb 21 09:27, Corinna Vinschen via Cygwin wrote:
> On Feb 20 21:39, Jeremy Drake via Cygwin wrote:
> > On Tue, 20 Feb 2024, Corinna Vinschen wrote:
> > 
> > > On Feb 19 21:41, Jeremy Drake via Cygwin wrote:
> > > > 1) is there actually a good reason that _cygheap_start is in the .rsrc 
> > > > and
> > > > not the .cygheap section?
> > >
> > > As you know we got rid of this way to define the cygheap, but
> > > _cygheap_start was just defined this way so it's the address marking
> > > the start address of the cygheap.
> > >
> > > It was just the way it was.  It's probably just as well to move
> > >
> > >   _SYM (_cygheap_start) = .;
> > >
> > > to the begining of the .cygheap section.  Did you try?
> > 
> > I hadn't; I have now and it seems to work fine.
> 
> I'm glad to read that.
> 
> > I basically assumed there
> > was some reason I wasn't aware of for putting it in the .rsrc section, so
> > focused more on trying to figure out how to get binutils to clear the
> > readonly section flag.  When I couldn't figure that out, I figured I'd ask
> > here both about the "institutional knowledge" if there was a known reason
> > why it needed to be in the .rsrc section and because I figured some people
> > knowledgable in binutils pe stuff might also read this and be able to give
> > me another idea on making the .rsrc section read/write again if it did
> > need to stay in that section.
> 
> I think there was some historical reason to put in .rsrc, or rather,
> into the section preceeding .cygheap, but I don't remember what it was.
> Might have had something to do with stripping the cygwin DLL or some
> such...

Actually, searching the history shows commit ce95c6407ef6a from
2005-06-01, which moves the definition of __cygheap_start from
the .cygheap section to the .idata section.  However, the commit
message only contains the hint "cygwin.sc: Modernize. [...]"
There's no other reason given ¯\_(ツ)_/¯


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: binutils >= 2.41 makes .rsrc section read-only

[Corinna Vinschen via Cygwin]

On Feb 20 21:39, Jeremy Drake via Cygwin wrote:
> On Tue, 20 Feb 2024, Corinna Vinschen wrote:
> 
> > On Feb 19 21:41, Jeremy Drake via Cygwin wrote:
> > > 1) is there actually a good reason that _cygheap_start is in the .rsrc and
> > > not the .cygheap section?
> >
> > As you know we got rid of this way to define the cygheap, but
> > _cygheap_start was just defined this way so it's the address marking
> > the start address of the cygheap.
> >
> > It was just the way it was.  It's probably just as well to move
> >
> >   _SYM (_cygheap_start) = .;
> >
> > to the begining of the .cygheap section.  Did you try?
> 
> I hadn't; I have now and it seems to work fine.

I'm glad to read that.

> I basically assumed there
> was some reason I wasn't aware of for putting it in the .rsrc section, so
> focused more on trying to figure out how to get binutils to clear the
> readonly section flag.  When I couldn't figure that out, I figured I'd ask
> here both about the "institutional knowledge" if there was a known reason
> why it needed to be in the .rsrc section and because I figured some people
> knowledgable in binutils pe stuff might also read this and be able to give
> me another idea on making the .rsrc section read/write again if it did
> need to stay in that section.

I think there was some historical reason to put in .rsrc, or rather,
into the section preceeding .cygheap, but I don't remember what it was.
Might have had something to do with stripping the cygwin DLL or some
such...


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: Cygwin installer hangs when running post-install scripts

[Corinna Vinschen via Cygwin]

On Feb 20 10:33, Kevin Ushey via Cygwin wrote:
> Hi Corinna,
> 
> I just updated 
> https://gist.github.com/kevinushey/cdbd15cdf22e5cdcd094b0ad80347dce
> with that output (windbg-output-2.txt); let me know if that gives you
> what you need.

Thank you!  Not sure I'll follow up on this, ARM64 assembler still
puzzles me.  However, this way I can at least take a look.


Thanks again,
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: BUG: Cygwin getent group refuses to list group added with net localgroup mygrp1 /add

[Corinna Vinschen via Cygwin]

On Feb 20 17:24, Dan Shelton via Cygwin wrote:
> On Tue, 20 Feb 2024 at 10:57, Corinna Vinschen via Cygwin
>  wrote:
> >
> > On Feb 20 05:13, Dan Shelton via Cygwin wrote:
> > > Hello!
> > >
> > > I think I found a rather nasty bug:
> > > 1. Add a new group with "net localgroup mygrp1 /add"
> > > 2. Then list all groups with "getent group", the new group mygrp1 will
> > > not show up. "getent group mygrp1" will list it, but this is useless
> > > in my case, as I need the group listed by "getent group"
> >
> > I guess we can rule out a domain controller but is this a standalone
> > machine or a domain member machine?
> 
> Standalone test machine, stock Windows 10 installed 2 days ago,
> current patches, Cygwin 3.5 from 2 days ago.
> 
> >
> > What's the setting of your /etc/nsswitch.conf?
> 
> Only comments in that file, i.e. empty

Please set the db_enum: line to

  db_enum: all

and try again after exiting from the shell window.  Have a look at
https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch
for the settings.  By default account enumeration only returns
the bare minimum for speed.

Btw, there *is* a bug in that code, but it affects only domain
menber machines, afaics.


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: BUG: gettimeofday() didn't handle first argument being NULL

[Corinna Vinschen via Cygwin]

On Feb 20 19:15, 109224573 via Cygwin wrote:
> this code works on Linux, but not msys2:
> 
> #include
> #include
> int main() {
>     struct timezone tz;
>     puts("a");
>     gettimeofday(NULL, &tz);
>     puts("b");
> }
> 
> 
> I guess the reason would be
> winsup/cygwin/times.cc

Thanks for the bug report.  Fixed in git.  The test release
cygwin-3.6.0-0.46.g70653fd8f1db containing this patch will be
available shortly.


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: binutils >= 2.41 makes .rsrc section read-only

[Corinna Vinschen via Cygwin]

On Feb 19 21:41, Jeremy Drake via Cygwin wrote:
> This is probably the right thing to do, but breaks building msys2-runtime
> (read: cygwin) 3.3, because the _cygheap_start symbol is actually in the
> .rsrc section and code very early attempts to memset _cygheap_start.
> Couple of questions:
> 
> 1) is there actually a good reason that _cygheap_start is in the .rsrc and
> not the .cygheap section?

As you know we got rid of this way to define the cygheap, but
_cygheap_start was just defined this way so it's the address marking
the start address of the cygheap.

It was just the way it was.  It's probably just as well to move

  _SYM (_cygheap_start) = .;

to the begining of the .cygheap section.  Did you try?


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: BUG: Cygwin getent group refuses to list group added with net localgroup mygrp1 /add

[Corinna Vinschen via Cygwin]

On Feb 20 05:13, Dan Shelton via Cygwin wrote:
> Hello!
> 
> I think I found a rather nasty bug:
> 1. Add a new group with "net localgroup mygrp1 /add"
> 2. Then list all groups with "getent group", the new group mygrp1 will
> not show up. "getent group mygrp1" will list it, but this is useless
> in my case, as I need the group listed by "getent group"

I guess we can rule out a domain controller but is this a standalone
machine or a domain member machine?

What's the setting of your /etc/nsswitch.conf?


Thanks,
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: Cygwin installer hangs when running post-install scripts

[Corinna Vinschen via Cygwin]

Hi Kevin,

On Feb 15 20:13, Corinna Vinschen via Cygwin wrote:
> On Feb 15 09:46, Kevin Ushey via Cygwin wrote:
> > https://gist.github.com/kevinushey/cdbd15cdf22e5cdcd094b0ad80347dce.
> [...]
>   0001`802b7054 db030094 bl  ntdll!#RtlpReferenceCurrentDirectory 
> (1802b7fc0)

I'm not familiar with ARM assembler, but a quick search showed that the
`bl' opcode is basically a subroutine call.

So ntdll!#RtlpReferenceCurrentDirectory is not the address of the struct
pointer, as I surmised, but the address of the function (probably)
fetching the address of the struct pointer.

Would you mind to send the assembler output for this function as well?


Thanks,
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: Group name madness: "CurrentSession" vs. "LogonSessionId_0_111590" vs. "NT AUTHORITY\LogonSessionId_0_111590" ...

[Corinna Vinschen via Cygwin]

On Feb 19 08:11, Roland Mainz via Cygwin wrote:
> Hi!
> 
> 
> 
> While implementing chown/chgrp support in the ms-nfs41-client (Windows
> NFSv4.1 client filesystem driver) I encountered an issue with group
> names.
> 
> I tried a simple $ chgrp CurrentSession myfile #, which returned
> "Permission denied".

Works for me:

  $ chgrp CurrentSession x.c
  $ ls -l x.c
  -rw-r--r-- 1 corinna CurrentSession 906 Jan 23 21:40 x.c
  $ icacls x.c
  x.c VINSCHEN\corinna:(R,W,D,WDAC,WO)
  NT AUTHORITY\LogonSessionId_0_2027255:(R)
  Everyone:(R)

  Successfully processed 1 files; Failed processing 0 files
  $

> OK, /usr/bin/id -a shows that the current user is a member of this
> group, so I added a new group called "CurrentSession" to the NFSv4.1
> server side ([1]).

Just don't do that.  This group is a *temporary* group which is created
from your login session ID.  Your login session is basically a pair of
two 32 bit values, generated via NtAllocateLocallyUniqueId().  From
there, Windows creates a SID

 S-1-5-5--

These days, when you call LookupAccountSidW() on this SID, you get the
info

  Domain: NT AUTHORITY
  Namme:  LogonSessionId_0_2027255

This SID is used inside your user token to connect your token with the
login session for which this token has been created.  It can be used for
authorization purposes, but it's not meant to be used as a SID in file
ownership, even though it's possible (basically any SID can be added
to files).

So, what's that about "CurrentSession" in Cygwin?

The reason is that this is historically what Interix did.  Keep in
mind that Interix (as well as Cygwin, but that doesn't matter here)
exist since Windows NT 3.5 times.

The above naming mechanism didn't exist at the time.  If you fetched the
Logon SID from the token and called LookupAccountSidW() on it, the call
failed, i. e., there was no name attached to the SID.

So... given that a Logon SID is unique to the logon session, given that
the SID has no unambiguous name attached, and given that the Logon SID
makes *no sense at all* outside its session, the Interix guys decided to
solve this little problem like this:

- If the inspected token contains the Logon SID equivalent to the
  current user session, call it "CurrentSession" with unique gid 4095.

- If the inspected token contains a Logon SID which is not attached
  to the current Logon Session we're running in, call it "OtherSession"
  with the non-unique gid 4094.

This is the model Cygwin follows as well.  The Logon SIDs shouldn't
really concern you in terms of file access.  From the user perspective
they are barely informative at all.  They *could* make sense in terms
of temporary files, but I don't know of any useful example.

> But that did not work either, /usr/bin/chgrp # still failed.

I can't tell you why it didn't work for you while it works out of the
box for me.  However, there isn't much sense in there to attach these
SIDs to a file.  Logout, login again, and you will have a new Logon SID
anyway ¯\_(ツ)_/¯


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: Cygwin sqlite locking debug options still available?

[Corinna Vinschen via Cygwin]

On Feb 17 14:38, Martin Wege via Cygwin wrote:
> On Tue, Feb 6, 2024 at 12:31 PM Martin Wege  wrote:
> >
> > Hello!
> >
> > Is the debug mode for sqlite locking mode as described in
> > https://cygwin.cygwin.narkive.com/nkjMGQga/test-sqlite3-3-7-17-1-1-7-19-locking-feature
> > soehow still available?
> >
> > We sometimes get sqlite locking errors, and like to investigate what
> > and why this fails
> 
> Corinna?

Sorry, I'm not the sqlite maintainer.

Also, I skimmed the above mail thread and I don't see any mention of a
specific debug mode in the above mail thread.


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: Cygwin installer hangs when running post-install scripts

[Corinna Vinschen via Cygwin]

On Feb 15 09:46, Kevin Ushey via Cygwin wrote:
> Thanks -- I've put the associated WinDbg output up at
> https://gist.github.com/kevinushey/cdbd15cdf22e5cdcd094b0ad80347dce.
> (Sharing it externally just because it's relatively large.)

Thank you!

> The important thing to note is that #RtlGetCurrentDirectory_U appears
> to be valid ARM assembly, but not x86_64 assembly. My hypothesis here
> is that the stub is used to allow emulated x86_64 processes to call
> back into native ARM code... which would further confirm that
> disabling the find_fast_cwd_pointer checks for ARM is the correct
> choice.

I guess so, but I'm quite puzzled how the emulator is supposed
to know that it just left the x86_64 assembler code.  Magic!!!

Checking the ARM code, it might even be possible to come up with
a real solution, given this line in the first few bytes of
ntdll!#RtlGetCurrentDirectory_U:

  0001`802b7054 db030094 bl  ntdll!#RtlpReferenceCurrentDirectory 
(1802b7fc0)

This seems to fetch the address of the pointer we're interested in.
It's unlikely (but not impossible) that the structure differs from the
same struct as on x86_64.

We may have a chance there, but I would feel better if I could debug my
code by myself.


Thanks,
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: Cygwin installer hangs when running post-install scripts

[Corinna Vinschen via Cygwin]

On Feb 14 13:49, Kevin Ushey via Cygwin wrote:
> Thanks for your patience. Here's what I've got for the assembly around
> get_dir. I added a bit of debug logging just so I could get the
> function addresses:

First of all, thanks for taking the time to debug this further!

> C:\cygwin\bin>cygpath
> get_dir = 0x7FFB85E251B0
> rcall = 0x7FFB85E251CB
> 
> And here's what WinDbg reports:
> 
> ntdll!EXP+#RtlGetCurrentDirectory_U:
> 7ffb`85e251b0 488bc4 mov rax, rsp
> 7ffb`85e251b3 48895820   mov qword ptr [rax+20h], rbx
> 7ffb`85e251b7 55 pushrbp
> 7ffb`85e251b8 5d pop rbp
> 7ffb`85e251b9 e9721e2b00 jmp ntdll!#RtlGetCurrentDirectory_U
> (7ffb860d7030)
> 7ffb`85e251be cc int 3
> 7ffb`85e251bf cc int 3
> ntdll!EXP+#RtlGetCurrentPeb:
> 7ffb`85e251c0 488bc4 mov rax, rsp
> 7ffb`85e251c3 48895820   mov qword ptr [rax+20h], rbx
> 7ffb`85e251c7 55 pushrbp
> 7ffb`85e251c8 5d pop rbp
> 7ffb`85e251c9 e9e2e82400 jmp ntdll!#RtlGetCurrentPeb (7ffb86073ab0)
> 7ffb`85e251ce cc int 3
> 7ffb`85e251cf cc int 3
> 
> I'm not sure what the "EXP+#" prefix here means, but it appears to
> just be a stub that calls into the real implementation now?

Yes, that seems to be the case, same EXP+#for RtlGetCurrentPeb.

> So, if I'm understanding correctly:
> 
> 1. Cygwin was expecting to find a 'call' instruction somewhere
> following (the procedure address for) RtlGetCurrentDirectory_U;
> 2. The expected 'call' instruction no longer exists; however, by
> chance, there is a 'jmp' later on that includes '0xe8' in the bytes of
> the address to be jumped to;

That's it.  Chances are high that the above ntdll code was always more
or less the same and find_fast_cwd_pointer() failed all the time.  Only,
it never found the "e8" and so nothing bad happened.

So, as long as we don't know how to fix this correctly, my patch
4e77fa9b8bf4 ("Cygwin: find_fast_cwd: don't run assembler checking code
on ARM64") seems the right thing to do.

What annoys me is that I don't have access to ARM64 myself.  I tried
to install Windows for ARM64 on a QEmu emulator, but the VM always
failed to boot into Windows, it just sat there and used up CPU.
I even contemplated installing an Azure ARM64 VM, but I always shy
away from cloud services at the point they ask you for your size of
shoe and your social security number.

Anyway...

> For reference, here's what I see on my Intel Windows 11 machine, where
> all works as normal (showing up to the "call" instruction)

I wonder if you would be willing to grant us a view into the
ntdll!#RtlGetCurrentDirectory_U function jumped to from
ntdll!EXP+#RtlGetCurrentDirectory_U.  Per your above assembler output,
that would be at 7ffb860d7030.  Would you mind to post the WinDBG
assembler output of that function as well, even if just for curiosity?


Thanks,
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: Cygwin installer hangs when running post-install scripts

[Corinna Vinschen via Cygwin]

On Feb 14 10:52, Corinna Vinschen via Cygwin wrote:
> On Feb 13 15:48, Kevin Ushey via Cygwin wrote:
> > Here's a bit more information from a debug build of cygwin; here I'm
> > just trying to launch cygpath.exe:
> > 
> > (gdb) f 1
> > #1  0x7ffa0123ba1f in find_fast_cwd_pointer () at
> > ../../../../winsup/cygwin/path.cc:4526
> > 4526  const uint8_t *lock = (const uint8_t *)
> > 
> > (gdb) bt
> > #0  memmem (haystack=, hs_len=,
> > needle=0x7ffa0142e531 <_C_collate_locale+59857>, ne_len=4) at
> > ../../../newlib/libc/string/memmem.c:161
> > #1  0x7ffa0123ba1f in find_fast_cwd_pointer () at
> > ../../../../winsup/cygwin/path.cc:4526
> > [...]
> 
> Ok, so we know now which memmem call fails, so the next question is,
> why?  The haystack address is unfortunately still optimized out in
> memmem, so it looks like the newlib subdir is still optimized.
> But it's pretty certainly a wrong haystack address.  This address has
> been fetched from
> 
>   const uint8_t *rcall = (const uint8_t *) memchr (get_dir, 0xe8, 80);
>   ...
>   const uint8_t *use_cwd = rcall + 5 + peek32 (rcall + 1);
> 
> Chances are high, that the call instruction found by rcall is bogus.

Can you run this in GDB?  I'd love to see the assembler code starting at
address `get_dir'...


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: Cygwin installer hangs when running post-install scripts

[Corinna Vinschen via Cygwin]

On Feb 13 15:48, Kevin Ushey via Cygwin wrote:
> Here's a bit more information from a debug build of cygwin; here I'm
> just trying to launch cygpath.exe:
> 
> (gdb) f 1
> #1  0x7ffa0123ba1f in find_fast_cwd_pointer () at
> ../../../../winsup/cygwin/path.cc:4526
> 4526  const uint8_t *lock = (const uint8_t *)
> 
> (gdb) bt
> #0  memmem (haystack=, hs_len=,
> needle=0x7ffa0142e531 <_C_collate_locale+59857>, ne_len=4) at
> ../../../newlib/libc/string/memmem.c:161
> #1  0x7ffa0123ba1f in find_fast_cwd_pointer () at
> ../../../../winsup/cygwin/path.cc:4526
> [...]

Ok, so we know now which memmem call fails, so the next question is,
why?  The haystack address is unfortunately still optimized out in
memmem, so it looks like the newlib subdir is still optimized.
But it's pretty certainly a wrong haystack address.  This address has
been fetched from

  const uint8_t *rcall = (const uint8_t *) memchr (get_dir, 0xe8, 80);
  ...
  const uint8_t *use_cwd = rcall + 5 + peek32 (rcall + 1);

Chances are high, that the call instruction found by rcall is bogus.

> Diving in further is a bit beyond my level of experience with Windows
> internals.

It would be great if you could run this under GDB and check the
assembler code inside the ntdll.dll this code is scanning.  You
don't really need knowledge of Windows internals, it's basically
just really dumb scanning of assembler code for certain instructions,
and the expected assembler code is x86_64.

> I wonder if it'd be
> worth having cygwin respect an environment variable like
> CYGWIN_USE_FAST_CWD_POINTER, so that users could opt out of this
> particular optimization if it happens to break on new versions of
> Windows, as I have seemingly encountered.

My latest patch already does it, no env var required.

> As an aside, I had to make a couple of small patches to side-step gcc
> warnings (converted to errors) during build; I tried building with "-g
> -Og" flags.

I'm usually building with -ggdb only, or with -ggdb -O2.

I just added -Og, and checked the below code.  I'm not so sure about the
usefulness of -Og, given that all three warnings are false positives...

> $ git diff
> diff --git a/winsup/cygwin/fhandler/fifo.cc b/winsup/cygwin/fhandler/fifo.cc
> index efea508ae..f288e874a 100644
> --- a/winsup/cygwin/fhandler/fifo.cc
> +++ b/winsup/cygwin/fhandler/fifo.cc
> @@ -669,7 +669,7 @@ fhandler_fifo::create_shmem (bool only_open)
>  {
>HANDLE sect;
>OBJECT_ATTRIBUTES attr;
> -  NTSTATUS status;
> +  NTSTATUS status = 0;
>LARGE_INTEGER size = { .QuadPart = sizeof (fifo_shmem_t) };
>SIZE_T viewsize = sizeof (fifo_shmem_t);
>PVOID addr = NULL;

My gcc (11.3.0) did not show this, even with -Og.  However, the status
var always gets set, see lines 685 - 695.

> diff --git a/winsup/cygwin/tty.cc b/winsup/cygwin/tty.cc
> index bf7c6010f..2cd4ae6ed 100644
> --- a/winsup/cygwin/tty.cc
> +++ b/winsup/cygwin/tty.cc
> @@ -323,7 +323,7 @@ tty::wait_fwd ()
>   thread when the last data is transfered. */
>const ULONGLONG sleep_in_nat_pipe = 16;
>const ULONGLONG time_to_wait = sleep_in_nat_pipe * 2 + 1/* margine */;
> -  ULONGLONG elapsed;
> +  ULONGLONG elapsed = 0;
>while (fwd_not_empty
>  || (elapsed = GetTickCount64 () - fwd_last_time) < time_to_wait)
>  {

fwd_not_empty is false for a start, so GetTickCount64() is called at
least once.

> diff --git a/winsup/utils/kill.cc b/winsup/utils/kill.cc
> index fb45e4c9d..bcabcd47c 100644
> --- a/winsup/utils/kill.cc
> +++ b/winsup/utils/kill.cc
> @@ -73,7 +73,7 @@ print_version ()
>  static const char *
>  strsigno (int signo)
>  {
> -  static char sigbuf[8];
> +  static char sigbuf[32];
> 
>if (signo > 0 && signo < SIGRTMIN)
>  return sys_sigabbrev[signo];

We're calling snprintf here for a reason, and we know that the
number has never more than 2 digits.  Oh well.


Thanks,
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: Cygwin installer hangs when running post-install scripts

[Corinna Vinschen via Cygwin]

On Feb 13 10:01, Kevin Ushey via Cygwin wrote:
> On Tue, Feb 13, 2024 at 8:25 AM Corinna Vinschen wrote:
> > On Feb 13 11:09, Corinna Vinschen via Cygwin wrote:
> > > Other than that, the only thing you really could do at this point is to
> > > check Cygwin's find_fast_cwd_pointer() function and go through this
> > > function step by step, diving into the assembler code this function
> > > inspects trying to find out which of the memmem calls fails and how to
> > > fix it.  And send a patch eventually.
> > > [...]
> > > One thing we can do is to skip the find_fast_cwd_pointer() code entirely
> > > when running on AArch64, but it's a bit annoying, given this wasn't
> > > necessary in previous AArch64 builds.
> >
> > I've just pushed a (temporary?) patch to do just that.  This will be
> > in the test build cygwin-3.6.0-0.37.g4e77fa9b8bf4 which will be
> > installable via Cygwin's installer in an hour or two.
> 
> Thank you for taking a look so quickly -- I can confirm your patch
> fixes things for me; the installer now runs to completion and the
> Cygwin64 Terminal + other installed tools all function correctly.

Thanks for confirming.  However, if you see *any* chance to check
Cygwin's find_fast_cwd_pointer() pointer function and try to find
out why it crashes, that would be very helpful.


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: Cygwin installer hangs when running post-install scripts

[Corinna Vinschen via Cygwin]

On Feb 13 11:09, Corinna Vinschen via Cygwin wrote:
> On Feb 12 14:38, Kevin Ushey via Cygwin wrote:
> > For reference, I first bumped into this when using Git Bash as bundled
> > with Git for Windows, but it sounds like the underlying issue may be
> > in Cygwin. See https://github.com/git-for-windows/git/issues/4808 for
> > more details.
> 
> There is, however, the stacktrace from your above issue report on
> github, which makes more sense, and, incidentally, occurs in code
> following cygwin_split_path in the .text segment:
> 
> (gdb) bt
> #0  0x0002101eeaf3 in memmem () from [...]
> #1  0x000210095d91 in cwdstuff::override_win32_cwd(bool, unsigned int) ()
>from [...]
> #2  0x00021009642e in cwdstuff::set(path_conv*, char const*) () from [...]
> #3  0x000210047025 in dll_crt0_1(void*) () from [...]
> #4  [...]
> 
> This points to something going wrong during startup, while trying
> to evaluate the global pointer to the hidden ntdll.dll struct we
> called, for want of an official expression, FAST_CWD structure.
> 
> If we can rely on frame 1, a call to memmem crashes, that would
> mean the crash occurs in find_fast_cwd_pointer().
> 
> > Does any of this sound familiar? Is there anything else I can do to
> > get more information here; e.g. are there builds of Cygwin with debug
> > symbols published somewhere, or should I try producing my own debug
> > build?
> 
> Well, you could have mentioned that this is on AArch64.  Fortunately
> you did in the github case, but next time, please tell us here, too.
> 
> I assume you can't run any Cygwin binary, even from outside the
> installer?
> 
> Other than that, the only thing you really could do at this point is to
> check Cygwin's find_fast_cwd_pointer() function and go through this
> function step by step, diving into the assembler code this function
> inspects trying to find out which of the memmem calls fails and how to
> fix it.  And send a patch eventually.
> 
> However, there isn't much point there as long as this is an insider
> build.  In the past, the code often changed and was uncritical in the
> next official release.
> 
> One thing we can do is to skip the find_fast_cwd_pointer() code entirely
> when running on AArch64, but it's a bit annoying, given this wasn't
> necessary in previous AArch64 builds.

I've just pushed a (temporary?) patch to do just that.  This will be
in the test build cygwin-3.6.0-0.37.g4e77fa9b8bf4 which will be
installable via Cygwin's installer in an hour or two.

Please try if this works for you and report back.  You can use this
DLL as workaround for the time being then.


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: Win32 account SID lookup if user and group have the same name?

[Corinna Vinschen via Cygwin]

On Feb 13 02:12, Dan Shelton via Cygwin wrote:
> Hello!
> 
> How can I get the SID for either user XOR group if both have the same
> name? Remember Cygwin, as Unix and Linux, allow that a user "danfsh"
> can have his own group "danfsh". That works fine there, but on Win32
> there is only LookupAccountSidA() which has no way to distinguish
> whether you want a user SID or a group SID.

User and group "danfsh" are NOT a user and a group.  Rather, there is
actually only one user account "danfsh" and Windows fills in your user
token with the *same* SID as primary group.

The weird thing in Windows is that it has no strict concept of groups.
The user token contains primary and supplementary group info, but the OS
can fill them with basically any SID it can lay its hands on.

And at one point (I'm deliberately vague here since I don't know exactly
when this occured), Microsoft started to fill in the primary group of
some local account with the user SID, rather than with the "None"(*)
group as is usually the default for local accounts.

(*) That's the local domain SID with RID 513. The name of the group
is actually localized.

> How can I get the SID for group "danfsh", or the SID for user "danfsh"?

It's the same SID and it's your user SID.  There can't be a group with
the same name as a user account in the same user DB.  Each account in
the local domain or in an AD domain has to have a unique account name.


HTH,
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: Cygwin installer hangs when running post-install scripts

[Corinna Vinschen via Cygwin]

On Feb 12 14:38, Kevin Ushey via Cygwin wrote:
> Hello,
> 
> I'm seeing an issue when attempting to install Cygwin where the
> installer hangs while trying to run postinstall scripts (more
> specifically, /etc/postinstall/0p_000_autorebase.dash). When the hang
> occurs, I see a 'dash.exe' process chewing up 100% of a CPU. If I
> attach to the process with WinDbg, I see:
> 
> (940.978): Access violation - code c005 (first chance)
> First chance exceptions are reported before any exception handling.
> This exception may be expected and handled.
> cygwin1!memmem+0xcb:
> 7ffa`490cbb1b 410fb60424  movzx   eax,byte ptr [r12]
> ds:7ffa`552651f7=??
> 0:000> k
>  #   Arch   Child-SP  RetAddr   Call Site
> 00AMD64 0007`c930 7ffa`48f8028f cygwin1!memmem+0xcb
> 01AMD64 0007`ca90 7ffa`48f80a49
> cygwin1!cygwin_split_path+0x3a0
> 02AMD64 0007`cb20 7ffa`48f37071
> cygwin1!cygwin_split_path+0xb5a
> 03AMD64 0007`cc50 7ffa`48f35e08
> cygwin1!cygwin_dll_init+0x26b
> 04AMD64 0007`cd80 7ffa`48f35e86 cygwin1!_assert+0x23f0
> 05AMD64 0007`cdd0 ` cygwin1!_assert+0x246e
> 
> I'm not sure how much I can trust the stack trace here, though.

I don't think this stacktrace makes any sense. cygwin_split_path
is a function only exported for historical reasons and not used
internally.  Dash doesn't call it either.

> For reference, I first bumped into this when using Git Bash as bundled
> with Git for Windows, but it sounds like the underlying issue may be
> in Cygwin. See https://github.com/git-for-windows/git/issues/4808 for
> more details.

There is, however, the stacktrace from your above issue report on
github, which makes more sense, and, incidentally, occurs in code
following cygwin_split_path in the .text segment:

(gdb) bt
#0  0x0002101eeaf3 in memmem () from [...]
#1  0x000210095d91 in cwdstuff::override_win32_cwd(bool, unsigned int) ()
   from [...]
#2  0x00021009642e in cwdstuff::set(path_conv*, char const*) () from [...]
#3  0x000210047025 in dll_crt0_1(void*) () from [...]
#4  [...]

This points to something going wrong during startup, while trying
to evaluate the global pointer to the hidden ntdll.dll struct we
called, for want of an official expression, FAST_CWD structure.

If we can rely on frame 1, a call to memmem crashes, that would
mean the crash occurs in find_fast_cwd_pointer().

> Does any of this sound familiar? Is there anything else I can do to
> get more information here; e.g. are there builds of Cygwin with debug
> symbols published somewhere, or should I try producing my own debug
> build?

Well, you could have mentioned that this is on AArch64.  Fortunately
you did in the github case, but next time, please tell us here, too.

I assume you can't run any Cygwin binary, even from outside the
installer?

Other than that, the only thing you really could do at this point is to
check Cygwin's find_fast_cwd_pointer() function and go through this
function step by step, diving into the assembler code this function
inspects trying to find out which of the memmem calls fails and how to
fix it.  And send a patch eventually.

However, there isn't much point there as long as this is an insider
build.  In the past, the code often changed and was uncritical in the
next official release.

One thing we can do is to skip the find_fast_cwd_pointer() code entirely
when running on AArch64, but it's a bit annoying, given this wasn't
necessary in previous AArch64 builds.


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: Cygwin build from source is broken since binutils-2.42-1

[Corinna Vinschen via Cygwin]

On Feb 12 11:10, Christian Franke via Cygwin wrote:
> This is not a binutils regression: A build from cygwin 3.5.0-1 src package
> or current newlib-cygwin git main (bfb68a9) with new binutils-2.42-1 fails
> with:
> 
> "
> In file included from ../../../../winsup/utils/dumper.cc:23:
> /usr/include/bfd.h:2748:1: error: expected initializer before
> ‘ATTRIBUTE_WARN_UNUSED_RESULT’
> "
> 
> Downgrading to binutils 2.41-3 fixes the problem.
> 
> A diff of /usr/include/bsd.h shows that ATTRIBUTE_WARN_UNUSED_RESULT is a
> new addition in 2.42-1. This requires /usr/include/ansidecl.h. It is
> included by /usr/include/bsd.h but this has no effect because Cygwin source
> tree provides its own ansidecl.h which lacks ATTRIBUTE_WARN_UNUSED_RESULT:
> 
> $ g++ MANY_OPTIONS... -E ../../../../winsup/utils/dumper.cc
> ...
> # 1 "../../../../winsup/utils/dumper.cc"
> ...
> # 1 "../../../../winsup/../include/ansidecl.h" 1  <== #define _ANSIDECL_H
> ...
> # 1 "/usr/include/bfd.h" 1 3 4
> ...
> # 1 "/usr/include/ansidecl.h" 1 3 4  <== #ifndef _ANSIDECL_H

Did you try to copy over include/ansidecl.h from binutils master
to newlib-cygwin's include/ansidecl.h?

It looks like this does the trick, together with changing
dumper.cc, because of:

winsup/utils/dumper.cc:145:48: error: ‘PTR’ has not been declared
  145 | print_section_name (bfd* abfd, asection* sect, PTR obj)
  |^~~

Changing this to "void*" fixes the build for binutils 2.40 on Linux.


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: Updated: setup (2.930)

[Corinna Vinschen via Cygwin]

On Feb  9 17:20, Corinna Vinschen via Cygwin wrote:
> On Feb  9 13:36, Jon Turney via Cygwin wrote:
> > On 09/02/2024 02:17, Kaz Kylheku via Cygwin wrote:
> > > 
> > > I see the commit: 
> > > https://cygwin.com/cgit/cygwin-apps/setup/commit/?id=0122154811bacdd7dc042cff0c80bb0a36af360c
> > > 
> > > I'm curious, what improvement arises out of looking up the 
> > > SetDefaultDllDirectories
> > > function dynamically in kernel32.dll?
> > > 
> > > Is it the case that malicious software can interpose itself somehow such 
> > > that
> > > the statically linked SetDefaultDllDirectories call goes elsewhere other 
> > > than
> > > kernel32.dll, which we can thwart by asking for the genuine article in 
> > > kernel32.dll?
> > 
> > You're looking at the wrong commit there.
> > 
> > The dynamic lookup merely ensures that setup continues to work at all on
> > Windows versions (<6.0), which don't support that function.
> 
> Typo.  Windows < 6.2.  SetDefaultDllDirectories has been introduced with
> Windows 8.

...and with KB2533623 it was also backported to Vista, W7, and the
equivalent server versions, so just ignore me.

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: Updated: setup (2.930)

[Corinna Vinschen via Cygwin]

On Feb  9 13:36, Jon Turney via Cygwin wrote:
> On 09/02/2024 02:17, Kaz Kylheku via Cygwin wrote:
> > 
> > I see the commit: 
> > https://cygwin.com/cgit/cygwin-apps/setup/commit/?id=0122154811bacdd7dc042cff0c80bb0a36af360c
> > 
> > I'm curious, what improvement arises out of looking up the 
> > SetDefaultDllDirectories
> > function dynamically in kernel32.dll?
> > 
> > Is it the case that malicious software can interpose itself somehow such 
> > that
> > the statically linked SetDefaultDllDirectories call goes elsewhere other 
> > than
> > kernel32.dll, which we can thwart by asking for the genuine article in 
> > kernel32.dll?
> 
> You're looking at the wrong commit there.
> 
> The dynamic lookup merely ensures that setup continues to work at all on
> Windows versions (<6.0), which don't support that function.

Typo.  Windows < 6.2.  SetDefaultDllDirectories has been introduced with
Windows 8.


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: cygsshd fails due to bad ownership or modes of /cygdrive/c/Users

[Corinna Vinschen via Cygwin]

On Feb  7 20:27, Corinna Vinschen via Cygwin wrote:
> On Feb  7 20:23, ASSI via Cygwin wrote:
> > Frank-Ulrich Sommer via Cygwin writes:
> > > I'm trying to run cygsshd on my PC with Windows 11 and connect from a
> > > linux machine. I have added the public key to
> > > /cygdrive/c/Users/xxx/.ssh/authorized_keys and created a symbolic link
> > > from  /cygdrive/c/Users/xxx/.ssh to /home/xxx/.ssh. As usual I checked
> > > the access rights and mode of the .ssh directory (700 and belongs to
> > > user xxx) and the authorized_keys file (600 and also belongs to user
> > > xxx) and also of the home directory (had to change ownership).
> > 
> > Just bind mount instead of symlinking .ssh and everything should work.
> 
> Assuming you have installed CYgwin under your own account, that's even
> better than utilizing "StrictModes"

Scratch the "Assuming you have installed Cygwin under your own account"
thingy.  The safe_path() function in OpenSSH checks the path of files
in your home dir only up to the home directory itself.  However, that
depends on

  $ getent passwd 

returning the correct home dir.

Personally I just use Cygwin's /home/corinna as home path and symlink
or bind mount the Windows stuff into it, e.g.

  $ ln -s /proc/cygdrive/c/Users/corinna ~/winhome


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: cygsshd fails due to bad ownership or modes of /cygdrive/c/Users

[Corinna Vinschen via Cygwin]

On Feb  7 20:23, ASSI via Cygwin wrote:
> Frank-Ulrich Sommer via Cygwin writes:
> > I'm trying to run cygsshd on my PC with Windows 11 and connect from a
> > linux machine. I have added the public key to
> > /cygdrive/c/Users/xxx/.ssh/authorized_keys and created a symbolic link
> > from  /cygdrive/c/Users/xxx/.ssh to /home/xxx/.ssh. As usual I checked
> > the access rights and mode of the .ssh directory (700 and belongs to
> > user xxx) and the authorized_keys file (600 and also belongs to user
> > xxx) and also of the home directory (had to change ownership).
> 
> Just bind mount instead of symlinking .ssh and everything should work.

Assuming you have installed CYgwin under your own account, that's even
better than utilizing "StrictModes"


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: cygsshd fails due to bad ownership or modes of /cygdrive/c/Users

[Corinna Vinschen via Cygwin]

On Feb  7 19:01, matthew patton via Cygwin wrote:
> > The problem seems to be that OpenSSH does not even arrive at checking the 
> >home diretory> or the .ssh directory. It starts checking every directory in 
> >the path and fails already at "/cygdrive/c/Users"
> I don't think we can win an argument with Theo over how misguided and 
> unnecessary meddling the OpenSSH code is being. Ownership that diverges from 
> 0 (or 2, or 18) should be a mere WARNING, not an ERROR until validity checks 
> get to the user's actual $HOME and/or  the authorized_keys directory+file. 
> /home in cygwin is just [OS drive]/cygwin64/home so that doesn't fix 
> anything. I personally set the Cygwin FSTAB to
> C:/Users /home  none    binary  0 0
> Unfortunately I think we need an #IFDEF on safe_path() to force it back into 
> it's lane.Anyone want to tangle with Theo?

You can switch off the extended path permission checks by
changing your /etc/sshd_config file.

See the "StrictModes" setting in `man sshd_config'


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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[Corinna Vinschen via Cygwin]

On Feb  3 13:39, Corinna Vinschen via Cygwin wrote:
> On Feb  2 19:51, Corinna Vinschen via Cygwin wrote:
> > On Feb  2 18:22, Corinna Vinschen via Cygwin wrote:
> > > On Feb  2 14:56, David Allsopp via Cygwin wrote:
> > > > On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote:
> > > > > Is it actually a safe bet that the error mode set by 
> > > > > SetThreadErrorMode
> > > > > is then propagated as process error mode to the child process?
> > > > >
> > > > > I have to ask that because Microsoft conveniently forgot to document
> > > > > this scenario in the MSDN docs.
> > > > 
> > > > :o) Never knowingly clear, are they! It would seem to be the intent of
> > > > SetThreadErrorMode that it would behave that way but who knows.
> > > > 
> > > > Happy to set up a quick experiment to check that it does work (i.e.
> > > > [...]
> > > Wanna try this?
> > [...]
> > However, it occured to me that this won't work at all.
> > [...]
> 
> Sorry to say that, but SetThreadErrorMode/CreateProcess don't do what we
> want them to do.  I just tested this myself with a modified Cygwin DLL
> (code below) and it turns out that the child process error mode is
> the same as the parent's process error mode.  Changing the thread
> error mode from the Cygwin default 3 (aka SEM_FAILCRITICALERRORS |
> SEM_NOGPFAULTERRORBOX) to 0 doesn't have any effect.
> [...etc.]

MSYS2 has introduced the environment variable option CYGWIN=winjitdebug.
I backported this patch now.  So default is back to propagating Cygwin's
error mode and if you want to reset the error mode of a non-Cygwin child
process back to OS default, just set the option, for instance, like
this:

  $ CYGWIN=winjitdebug env 

This patch will be in Cygwin 3.5.1.  For the time being, it will be
available in the next test release cygwin-3.6.0-0.28.g918c3eda4176 as
well.


HTH,
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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[Corinna Vinschen via Cygwin]

On Feb  2 19:51, Corinna Vinschen via Cygwin wrote:
> On Feb  2 18:22, Corinna Vinschen via Cygwin wrote:
> > On Feb  2 14:56, David Allsopp via Cygwin wrote:
> > > On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote:
> > > > Is it actually a safe bet that the error mode set by SetThreadErrorMode
> > > > is then propagated as process error mode to the child process?
> > > >
> > > > I have to ask that because Microsoft conveniently forgot to document
> > > > this scenario in the MSDN docs.
> > > 
> > > :o) Never knowingly clear, are they! It would seem to be the intent of
> > > SetThreadErrorMode that it would behave that way but who knows.
> > > 
> > > Happy to set up a quick experiment to check that it does work (i.e.
> > > [...]
> > Wanna try this?
> [...]
> However, it occured to me that this won't work at all.
> [...]

Sorry to say that, but SetThreadErrorMode/CreateProcess don't do what we
want them to do.  I just tested this myself with a modified Cygwin DLL
(code below) and it turns out that the child process error mode is
the same as the parent's process error mode.  Changing the thread
error mode from the Cygwin default 3 (aka SEM_FAILCRITICALERRORS |
SEM_NOGPFAULTERRORBOX) to 0 doesn't have any effect.

Check the below Cygwin patch and look at output ("gem" is my MingW test
app just printing the process error mode retrieved via GetErrorMode):

  $ ./gem
0 [main] dash 990 child_info_spawn::worker: 1 = SetThreadErrorMode (0, 
0) GT:0 GP:3
16158 [main] dash 990 child_info_spawn::worker: 1 = SetThreadErrorMode (3, 
0)
  Error mode 0x3
  $

The terrible thing here is the output of the old thread error mode
from GetThreadErrorMode as well as from SetThreadErrorMode.

MSDN says:

  Each process has an associated error mode that indicates to the system
  how the application is going to respond to serious errors. A thread
  inherits the error mode of the process in which it is running. To
  retrieve the process error mode, use the GetErrorMode function. To
  retrieve the error mode of the calling thread, use the
  GetThreadErrorMode function.

What that means is, even though the process error mode is 3 , and even
though "A thread inherits the error mode of the process in which it is
running", GetThreadErrorMode/SetThreadErrorMode return a thread error
code of 0!!!

So if GetThreadErrorMode returns 0, you *have* to call GetErrorMode to
retrieve the *actual* thread error mode, because the thread error mode
just says "yo man, it's default".

In extension this probably *also* means, setting the thread error mode
to 0 does NOT mean "set it to system default" as MSDN claims, but it
means "set it to process default".

But in fact, even if I set a non-0 thread error mode, this has no effect
on the child process.  I forced the thread error mode to 1 before calling
CreateProcess, and the resulting child process error mode was still the
Cygwin process error mode 3.

Isn't that completely screwed up?

Ok, my Cygwin DLL test patch follows below.


Corinna


diff --git a/winsup/cygwin/dcrt0.cc b/winsup/cygwin/dcrt0.cc
index a40129c22232..14ba4e3769f1 100644
--- a/winsup/cygwin/dcrt0.cc
+++ b/winsup/cygwin/dcrt0.cc
@@ -718,7 +718,8 @@ dll_crt0_0 ()
   init_windows_system_directory ();
   initial_env ();
 
-  SetErrorMode (SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
+  UINT proc_error_mode = SetErrorMode (SEM_FAILCRITICALERRORS
+  | SEM_NOGPFAULTERRORBOX);
 
   lock_process::init ();
   user_data->impure_ptr = _impure_ptr;
@@ -738,6 +739,13 @@ dll_crt0_0 ()
   if (!child_proc_info)
 {
   setup_cygheap ();
+  /* Memorize the original error mode when this Cygwin process
+has been called from a non-Cygwin process.  We restore to
+this error mode on spawning a non-Cygwin process.  This allows
+to set a non-default error mode prior to calling the first
+Cygwin process and forward it to any subsequent non-Cygwin
+child process at spawn time. */
+  cygheap->orig_proc_error_mode = proc_error_mode;
   memory_init ();
 }
   else
diff --git a/winsup/cygwin/local_includes/cygheap.h 
b/winsup/cygwin/local_includes/cygheap.h
index b6acdf7f18b7..02e3cb4621e3 100644
--- a/winsup/cygwin/local_includes/cygheap.h
+++ b/winsup/cygwin/local_includes/cygheap.h
@@ -517,6 +517,7 @@ struct init_cygheap: public mini_cygheap
   mode_t umask;
   LONG rlim_as_id;
   unsigned long rlim_core;
+  UINT orig_proc_error_mode; /* Set when started from non-Cygwin process */
   HANDLE console_h;
   cwdstuff cwd;
   dtable fdtab;
diff --git a/winsup/cygwin/spawn.cc b/winsup/cygwin/spawn.cc
index 8a2db5cf72e2..85dbec431b28 100644
--- a/winsup/cygwin/spawn.cc
+++ b/winsup/cygwin/spawn.cc
@@ -401,13 +401

Re: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[Corinna Vinschen via Cygwin]

On Feb  2 18:22, Corinna Vinschen via Cygwin wrote:
> On Feb  2 14:56, David Allsopp via Cygwin wrote:
> > On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote:
> > > On Feb  2 13:35, David Allsopp via Cygwin wrote:
> > > > Not really suggesting it be done this way (it feels more complicated
> > > > than just reverting the change), but in some ways perhaps Cygwin
> > > > should be using GetErrorMode on startup and instead of not inheriting
> > > > it, ensuring that it sets whatever it received? i.e. just before the
> > > > call to CreateProcess for a non-Cygwin binary, Cygwin restores the
> > > > error mode (for that thread only) to the value read at startup, calls
> > > > CreateProcess and then sets the error mode back.
> > >
> > > This sounds like a good ide, but...
> > >
> > > Is it actually a safe bet that the error mode set by SetThreadErrorMode
> > > is then propagated as process error mode to the child process?
> > >
> > > I have to ask that because Microsoft conveniently forgot to document
> > > this scenario in the MSDN docs.
> > 
> > :o) Never knowingly clear, are they! It would seem to be the intent of
> > SetThreadErrorMode that it would behave that way but who knows.
> > 
> > Happy to set up a quick experiment to check that it does work (i.e.
> > the invoked process has GetErrorMode set as expected) and that there's
> > no possible race between two threads in the calling process with
> > differing values (i.e. that having SEM_FAILCRITICALERRORS in one
> > thread and not in another behaves as expected. If it does appear to
> > work consistently, would you be willing to go down this route? Happy
> > to do the patch, although it'd be very helpful to have a couple of
> > pointers: I'm guessing the value would want to be captured just before
> > the one place where SetErrorMode is already called, but in which
> > structure should it then be stashed away to be reused in spawn?
> 
> Wanna try this?  It ignores the case of starting a process
> under another user account for now, but that can be added easily
> if this proves to work as expected.

During dinner it occured to me that I forgot to remove setting the
default error mode via CreateProcess.  So this patch would have
to be applied as well:

diff --git a/winsup/cygwin/spawn.cc b/winsup/cygwin/spawn.cc
index 8a2db5cf72e2..2e0f0fcf2146 100644
--- a/winsup/cygwin/spawn.cc
+++ b/winsup/cygwin/spawn.cc
@@ -401,13 +401,6 @@ child_info_spawn::worker (const char *prog_arg, const char 
*const *argv,
 
   c_flags |= CREATE_SEPARATE_WOW_VDM | CREATE_UNICODE_ENVIRONMENT;
 
-  /* Add CREATE_DEFAULT_ERROR_MODE flag for non-Cygwin processes so they
-get the default error mode instead of inheriting the mode Cygwin
-uses.  This allows things like Windows Error Reporting/JIT debugging
-to work with processes launched from a Cygwin shell. */
-  if (!real_path.iscygexec ())
-   c_flags |= CREATE_DEFAULT_ERROR_MODE;
-
   /* We're adding the CREATE_BREAKAWAY_FROM_JOB flag here to workaround
 issues with the "Program Compatibility Assistant (PCA) Service".
 For some reason, when starting long running sessions from mintty(*),

However, it occured to me that this won't work at all.

Consider fork/exec.  In Windows terms, the forked process is a child
process started with CreateProcess.  The forked child is a Cygwin
process, so at DLL init time, it sets

  orig_proc_error_mode = SetErrorMode (SEM_FAILCRITICALERRORS
   | SEM_NOGPFAULTERRORBOX);

However, given the parent is always a Cygwin parent, orig_proc_error_mode
will always be SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX.

The following exec starting a non-Cygwin process will set the thread
error mode to the above value.  So any non-Cygwin process started from
your typical Cygwin process like bash, will always have the error mode
set to the same mode as any Cygwin application.

Ultimately this means, the effect is the same as if we had just reverted
commit 21ec498d7f912 ("cygwin: use CREATE_DEFAULT_ERROR_MODE in spawn").


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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[Corinna Vinschen via Cygwin]

On Feb  2 14:56, David Allsopp via Cygwin wrote:
> On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote:
> > On Feb  2 13:35, David Allsopp via Cygwin wrote:
> > > Not really suggesting it be done this way (it feels more complicated
> > > than just reverting the change), but in some ways perhaps Cygwin
> > > should be using GetErrorMode on startup and instead of not inheriting
> > > it, ensuring that it sets whatever it received? i.e. just before the
> > > call to CreateProcess for a non-Cygwin binary, Cygwin restores the
> > > error mode (for that thread only) to the value read at startup, calls
> > > CreateProcess and then sets the error mode back.
> >
> > This sounds like a good ide, but...
> >
> > Is it actually a safe bet that the error mode set by SetThreadErrorMode
> > is then propagated as process error mode to the child process?
> >
> > I have to ask that because Microsoft conveniently forgot to document
> > this scenario in the MSDN docs.
> 
> :o) Never knowingly clear, are they! It would seem to be the intent of
> SetThreadErrorMode that it would behave that way but who knows.
> 
> Happy to set up a quick experiment to check that it does work (i.e.
> the invoked process has GetErrorMode set as expected) and that there's
> no possible race between two threads in the calling process with
> differing values (i.e. that having SEM_FAILCRITICALERRORS in one
> thread and not in another behaves as expected. If it does appear to
> work consistently, would you be willing to go down this route? Happy
> to do the patch, although it'd be very helpful to have a couple of
> pointers: I'm guessing the value would want to be captured just before
> the one place where SetErrorMode is already called, but in which
> structure should it then be stashed away to be reused in spawn?

Wanna try this?  It ignores the case of starting a process
under another user account for now, but that can be added easily
if this proves to work as expected.

diff --git a/winsup/cygwin/dcrt0.cc b/winsup/cygwin/dcrt0.cc
index a40129c22232..f1017e69b6b2 100644
--- a/winsup/cygwin/dcrt0.cc
+++ b/winsup/cygwin/dcrt0.cc
@@ -718,7 +718,8 @@ dll_crt0_0 ()
   init_windows_system_directory ();
   initial_env ();
 
-  SetErrorMode (SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
+  orig_proc_error_mode = SetErrorMode (SEM_FAILCRITICALERRORS
+  | SEM_NOGPFAULTERRORBOX);
 
   lock_process::init ();
   user_data->impure_ptr = _impure_ptr;
diff --git a/winsup/cygwin/globals.cc b/winsup/cygwin/globals.cc
index 885ada85e7b8..d2861ba98b42 100644
--- a/winsup/cygwin/globals.cc
+++ b/winsup/cygwin/globals.cc
@@ -28,6 +28,7 @@ PWCHAR windows_directory = windows_directory_buf + 4;
 UINT windows_directory_length;
 UNICODE_STRING windows_directory_path;
 WCHAR global_progname[NT_MAX_PATH];
+UINT orig_proc_error_mode;
 
 /* program exit the program */
 
diff --git a/winsup/cygwin/spawn.cc b/winsup/cygwin/spawn.cc
index 8a2db5cf72e2..df83f25d13c6 100644
--- a/winsup/cygwin/spawn.cc
+++ b/winsup/cygwin/spawn.cc
@@ -648,6 +648,10 @@ child_info_spawn::worker (const char *prog_arg, const char 
*const *argv,
  && !::cygheap->user.groups.issetgroups ()
  && !::cygheap->user.setuid_to_restricted))
{
+ UINT orig_thread_error_mode = SEM_FAILCRITICALERRORS
+   | SEM_NOGPFAULTERRORBOX;
+ if (!iscygwin ())
+   SetThreadErrorMode (orig_proc_error_mode, &orig_thread_error_mode);
  rc = CreateProcessW (runpath, /* image name w/ full path */
   cmd.wcs (wcmd),  /* what was passed to exec */
   sa,  /* process security attrs */
@@ -658,6 +662,8 @@ child_info_spawn::worker (const char *prog_arg, const char 
*const *argv,
   NULL,
   &si,
   &pi);
+ if (!iscygwin ())
+   SetThreadErrorMode (orig_thread_error_mode, NULL);
}
   else
{

-- 
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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[Corinna Vinschen via Cygwin]

On Feb  2 13:35, David Allsopp via Cygwin wrote:
> Jon Turney via Cygwin wrote:
> 
> > > I'm sympathetic, and personally I would prefer to revert the patch and
> > > stick to SEM_FAILCRITICALERRORS by default.
> > >
> > > The question is this: Why does, apparently, everybody expect Cygwin to
> > > do the "right thing", with different definitions of "right", when in
> > > fact the executable in question can easily call SetErrorMode by itself?
> >
> > Yeah, if cygwin wasn't involved in the process ancestry, how would you
> > get the behaviour you want?
> 
> Ah, but that's how I hit this (and started digging further) -
> precisely because the non-Cygwin program I'm using _has_ called
> SetErrorMode and its direct calls to the faulty program _are_ doing
> what's wanted (no popup dialog) but the calls which happen via Cygwin
> are then torching that preference.
> 
> Not really suggesting it be done this way (it feels more complicated
> than just reverting the change), but in some ways perhaps Cygwin
> should be using GetErrorMode on startup and instead of not inheriting
> it, ensuring that it sets whatever it received? i.e. just before the
> call to CreateProcess for a non-Cygwin binary, Cygwin restores the
> error mode (for that thread only) to the value read at startup, calls
> CreateProcess and then sets the error mode back.

This sounds like a good ide, but...

Is it actually a safe bet that the error mode set by SetThreadErrorMode
is then propagated as process error mode to the child process?

I have to ask that because Microsoft conveniently forgot to document
this scenario in the MSDN docs.


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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[Corinna Vinschen via Cygwin]

On Feb  2 09:43, David Allsopp via Cygwin wrote:
> On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin
>  wrote:
> >
> > The behaviour changed in 2020
> >
> > https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912
> >
> > not without a discussion
> >
> > https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html
> 
> Aha, thank you! (congrats on the 3.5 release, in passing, btw).
> Definitely not a regression, then (subject edited).
> 
> However, this patch came from MSYS2, and subsequently they seem to
> have found it problematic for the same reason as me
> (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624)
> and have just recently reintroduced the flag
> (https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50)
> to control it.
> 
> The reasoning in
> https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as
> valid now as it did in 2006.
> 
> Is it possible to revisit having the flag, or even just reverting the 
> behaviour?
> 
> FWIW, it's been "hurting" us over in OCaml-land since zstd support was
> added roughly a year ago - configure can tell us that mingw-w64's zstd
> is available, but woe betide us if we run the test program to see if
> it actually works, but the user forgot to add the sys-root into PATH,
> because at that point the CI system is down...

I'm sympathetic, and personally I would prefer to revert the patch and
stick to SEM_FAILCRITICALERRORS by default.

The question is this: Why does, apparently, everybody expect Cygwin to
do the "right thing", with different definitions of "right", when in
fact the executable in question can easily call SetErrorMode by itself?


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

[ANNOUNCEMENT] cygwin 3.5.0-1

[Corinna Vinschen via Cygwin]

I'm happy to announce update of the first Cygwin 3.5 release

==
   IMPORTANT DEPRECATION NOTES
==

- Cygwin 3.4.10 was the LAST major version supporting

  - Windows 7 / 8
  - Windows Server 2008 R2 / 2012

- Cygwin 3.5.0 runs on

  - Windows 8.1 / 10 / 11
  - Windows Server 2012 R2 / 2016 / 2019 / 2022
  - and (hopefully) all upcoming releases of Windows.

==

Here's what's new and changed compared to Cygwin 3.4.10:


What's new:
---

- Drop support for Windows 7, Windows 8, Server 2008 R2 and Server 2012.

- Console devices (/dev/consN) are now accessible by processes attached
  to other consoles or ptys. Thanks to this new feature, GNU screen and
  tmux now work in the console.

- newgrp(1) tool.

- cygcheck has new options searching for available packages in the
  cygwin distro, as well as getting extended info on available and
  installed packages.

- fnmatch(3) and glob(3) now support named character classes, equivalence
  class expressions, and collating symbols in the search pattern, i.e.,
  [:alnum:], [=a=], [.aa.].

- Introduce /dev/disk directory with various by-* subdirectories which
  provide symlinks to disk and partition raw devices:
  by-drive/DRIVE_LETTER ->  ../../sdXN
  by-label/VOLUME_LABEL ->  ../../sdXN
  by-id/BUSTYPE-[VENDOR_]PRODUCT_[SERIAL|0xHASH][-partN] -> ../../sdX[N]
  by-partuuid/MBR_SERIAL-OFFSET -> ../../sdXN
  by-partuuid/GPT_GUID -> ../../sdXN
  by-uuid/VOLUME_SERIAL -> ../../sdXN
  by-voluuid/MBR_SERIAL-OFFSET -> ../../sdXN
  by-voluuid/VOLUME_GUID -> ../../sdXN
  The subdirectories by-drive and by-voluuid are Cygwin specific.

- Introduce /proc/codesets and /proc/locales with information on
  supported codesets and locales for all interested parties.  Locale(1)
  opens these files and uses the info for printing locale info like any
  other process could do.

- Add support for GB18030 codeset.

- Add support for lseek flags SEEK_DATA and SEEK_HOLE, a GNU extension.

- New API calls: posix_spawn_file_actions_addchdir_np,
  posix_spawn_file_actions_addfchdir_np.

- New API calls: c8rtomb, c16rtomb, c32rtomb, mbrtoc8, mbrtoc16, mbrtoc32.

- New API call: close_range (available on FreeBSD and Linux).

- New API call: fallocate (Linux-specific).

- Implement OSS-based sound mixer device (/dev/mixer).


What changed:
-

- posix_spawnp no longer falls back to starting the shell for unrecognized
  files as execvp.  For the reasoning, see
  https://www.austingroupbugs.net/view.php?id=1674

- FIFOs now also work on NFS filesystems.

- Enable automatic sparsifying of files on SSDs, independent of the
  "sparse" mount mode.

- When RLIMIT_CORE is more than 1MB, a core dump file which can be loaded by gdb
  is now written on a fatal error. Otherwise, if it's greater than zero, a text
  format .stackdump file is written, as previously.

- The default RLIMIT_CORE is now 0, disabling the generation of core dump or
  stackdump files.


Fixes:
--

- Fix arc4random reseeding after fork(2).
  Addresses: https://cygwin.com/pipermail/cygwin/2024-January/255245.html
-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

-- 
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: Aren't Windows System Error popups meant to be disabled in Cygwin?

[Corinna Vinschen via Cygwin]

On Feb  1 08:22, David Allsopp via Cygwin wrote:
> > x86_64-w64-mingw32-gcc produces a Windows program, why Cygwin should
> > be involved in the execution ?
> 
> I perhaps should have made that crystal clear - in running "./test",
> I'm invoking that excecutable _from_ a Cygwin program (in this case
> mintty / bash / sh), so Cygwin is very much involved - it's the
> caller.
> 
> In the actual problem which hit this, I have a non-Cygwin executable
> which has called SetErrorMode(SEM_FAILCRITICALERRORS). If that program
> calls test, there is no popup displayed. However, it also calls
> Cygwin's sh and _that_ executes that program too, so something like
> "C:\cygwin64\bin\sh -c "./test.exe | sed ..." but then the popup error
> message appears. So somewhere along the line, Cygwin appears to be
> resetting the system error mode, and that appears contrary to previous
> (old) messages on the subject.

The behaviour changed in 2020

https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912

not without a discussion

https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html


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: CYGWIN 1.5.3 END OF SUPPORT OR LIFE

[Corinna Vinschen via Cygwin]

Sorry, I have to correct myself in terms of the license:

On Jan 30 16:16, Corinna Vinschen via Cygwin wrote:
> Hi Marvin,
> 
> On Jan 29 22:24, Marvin.C.Scott--- via Cygwin wrote:
> > Good day -
> > 
> > I represent a logistics team of users of CYGWIN freeware for a
> > government contract. In my role I am responsible for tracking support
> > and end of life for software assets.
> > 
> > In the before mentioned effort mentioned above I have a general
> > question.
> > 
> > Do CYGWIN freeware developers or contributors enact any end or
> 
> Careful, please.  Cygwin is NOT freeware!
> 
> Cygwin is licensed per the GNU General Public License version 3(*), and
> that contains a couple of restrictions and responsibilities you should
> be aware of.  If you're unsure about the difference, I urge you to
> contact your company's laywer to make sure you're in the clear.

Cygwin 1.5.3 was not yet under GPL v3.  Back in 2003, Cygwin was
still under the CYGWIN license, which was going like this:

--
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License (GPL) as published by
the Free Software Foundation; either version 2 of the License, or (at
your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
--

*** NOTE ***

In accordance with section 10 of the GPL, Red Hat permits programs whose
sources are distributed under a license that complies with the Open
Source definition to be linked with libcygwin.a without libcygwin.a
itself causing the resulting program to be covered by the GNU GPL.

This means that you can port an Open Source(tm) application to cygwin,
and distribute that executable as if it didn't include a copy of
libcygwin.a linked into it.  Note that this does not apply to the cygwin
DLL itself.  If you distribute a (possibly modified) version of the DLL
you must adhere to the terms of the GPL, i.e. you must provide sources
for the cygwin DLL.

See http://www.opensource.org/docs/definition_plain.html for the precise Open 
Source
Definition referenced above.

Red Hat sells a special Cygwin License for customers who are unable to
provide their application in open source code form.  For more
information, please see: http://www.redhat.com/software/tools/cygwin/,
or call 866-2REDHAT ext.  3007
--

The "special Cygwin License for customers who are unable to provide
their application in open source code form" is not active anymore.
Given that, you have to comply with the general rule of the GPL v2,
plus the GPL section 10 exception.

I.e., you *must not* provide proprietary software linked to the 
Cygwin DLL to your customers.

If in doubt, contact your company lawyer!


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: CYGWIN 1.5.3 END OF SUPPORT OR LIFE

[Corinna Vinschen via Cygwin]

Hi Marvin,

On Jan 29 22:24, Marvin.C.Scott--- via Cygwin wrote:
> Good day -
> 
> I represent a logistics team of users of CYGWIN freeware for a
> government contract. In my role I am responsible for tracking support
> and end of life for software assets.
> 
> In the before mentioned effort mentioned above I have a general
> question.
> 
> Do CYGWIN freeware developers or contributors enact any end or

Careful, please.  Cygwin is NOT freeware!

Cygwin is licensed per the GNU General Public License version 3(*), and
that contains a couple of restrictions and responsibilities you should
be aware of.  If you're unsure about the difference, I urge you to
contact your company's laywer to make sure you're in the clear.

> specific date when versions downloaded are available to users?

No, we don't.  In fact, there's even a "Cygwin time machine" on the
net(**), where you can grab basically any old version of Cygwin.

> I pose this question as my users currently employ a version prior the
> latest 3.4.9-1 September 2023 release. I assume the only negative
> impacts of using earlier version would be that my team would not have
> current bug fixes.

That's the gist of it, plus new features or changed behaviour to
more closely follow POSIX.

However, if your users actually use version 1.5.3, as the subject of
your mail implies, they are using a version which is more than 20(!)
years old.

Also, Cygwin 1.5.3 only exists in a 32 bit version.

Given that practically all recent hardware is 64 bit, most users of
Cygwin switched to 64 bit versions of Windows, and recent Cygwin
versions (3.4.0 and later) are only available as 64 bit versions,
you're *very* far behind.  We can't give any kind of support For
20 years old Cygwin releases, naturally.


Corinna

(*) https://www.gnu.org/licenses/gpl-3.0.en.html
(**) http://www.crouchingtigerhiddenfruitbat.org/Cygwin/timemachine.html

-- 
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: arc4random does not reseed after using fork()

[Corinna Vinschen via Cygwin]

Hi Johnothan,

On Jan 26 22:06, Johnothan King via Cygwin wrote:
> Hello,
> 
> While testing ksh93u+m's recently added SRANDOM variable[1], I have
> discovered a bug in Cygwin's arc4random function. After using fork(),
> arc4random does not reseed itself, which causes the results to become
> predictable[2]. Below is a test case C program exhibiting the bug:
> 
> #include 
> #include 
> #include 
> #include 
> int main(void)
> {
>   pid_t child = fork();
>   if(child==0)
>   {
>   printf("%u %u %u\n", arc4random(), arc4random(), arc4random());
>   return 0;
>   }
>   else if(child==-1)
>   return 1;
>   waitpid(child, NULL, 0);
>   printf("%u %u %u\n", arc4random(), arc4random(), arc4random());
>   return 0;
> }

Thanks for the testcase.  I fixed that for Cygwin 3.5.  Please
try the latest test release cygwin-3.5.0-0.617.g030a762535c1,
which should be finished building in about an hour.


Thanks,
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: Setting process command name in forked process

[Corinna Vinschen via Cygwin]

On Jan 26 18:35, Steve Beck via Cygwin wrote:
> Thanks so much for the reply, Anton!  Really appreciate it.
> 
> I tried what you proposed.  Here is the code trying both ways
> (overwriting what is referenced by __argv[0] and then reassigning the
> reference).  I compile this code (foo.c) simply as follows: gcc -o foo
> foo.c (with no errors or warnings):
> 
> [...]
> if (fork() == 0)
> {
> extern  char**__argv;
> 
> strcpy(__argv[0], "bar");

Don't do that.  It's much too dangerous.

> __argv[0] = "bar";

That's ok, but see below.

> printf("Retry in Child '%s' (argv[0]) with pid %d setting 
> __argv[0] = 'bar': ps ...\n", argv[0], getpid());
> system("ps");

Make sure to install the procps-ng package, and then call

  system("procps -f");

> Here is the output when running foo.exe:
> [...]
> Retry in Child 'bar' (argv[0]) with pid 498 setting __argv[0] = 'bar': ps ...
>   PIDPPIDPGID WINPID   TTY UIDSTIME COMMAND
>   446 445 446 108276  pty0 1207519 10:19:37 /usr/bin/bash
>   445   1 445 126652  ?1207519 10:19:36 
> /usr/bin/mintty
>   498 497 497 128424  pty0 1207519 10:26:41 
> /home/sbeck/foo
>   497 446 497 123772  pty0 1207519 10:26:41 
> /home/sbeck/foo
>   500 498 497 128948  pty0 1207519 10:26:41 /usr/bin/ps
> 
> As you can see, in neither case does the ps command seem to accurately
> reflect the change in __argv[0] (although within the program, the
> change occurs to argv[0]).
> 
> Can you see what I'm doing wrong?

Actually, that's not your fault.  ps(1) from the cygwin base package
does not support this kind of faking the process name, because it does
not even get the command line of a process.  The information given to
ps(1) is pretty minimal and doesn't allow for stuff like that.  The
process name is always the real executable path the process has been
started through.

However, there's the ps(1) from the procps-ng package, which is called
procps.exe so as not to collide with the basic Cygwin ps.  This ps
fetches process information from /proc, which *is* updated when you
change __argv[0], because the info is fetched in realtime from the
process itself.

So with `procps -f', the output looks like this:

Retry in Child './foo' (argv[0]) with pid 570 setting __argv[0] = 'bar': ps ...
UIDPID  PPID  C STIME TTY  TIME CMD
corinna569   496 15 10:49 pty0 00:00:00 ./foo
corinna570   569 19 10:49 pty0 00:00:00 bar
corinna571   570 99 10:49 pty0 00:00:00 procps -f
corinna496   495  0 10:18 pty0 00:00:00 -tcsh

Bottom line:

Cygwin does not support this officially.  Changing the global __argv[0]
is a bad hack.  It works, but is non-portable.  In fact, there is no
portable way to do this.  SOme systems have prctl, some have
setproctitle, and some have nothing like this at all, stock Windows for
example.

It's also too late to add something along these lines to Cygwin 3.5,
which is due this week.

What we can do is to support this in the next major version of Cygwin,
in which case I'd prefer to implement this via setproctitle(3), given
this API exists on BSD and Linux.  Whether that implies changing
Cygwin's very simple ps(1) as well, I can't say yet.


HTH,
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: Possiblly bug of cygwin1.dll

[Corinna Vinschen via Cygwin]

On Jan 24 14:05, Corinna Vinschen via Cygwin wrote:
> On Jan 24 20:55, Takashi Yano via Cygwin wrote:
> > On Mon, 22 Jan 2024 19:24:52 -0800
> > Kaz Kylheku wrote:
> > > In real systems, the static distinction has no meaning.
> > > 
> > > This code can be inside a shared library:
> > > 
> > >static pthread_mutex_t g_lock = PTHREAD_MUTEX_INITIALIZER;
> > > 
> > > this library could be loaded by dlopen and unloaded with dlclose.
> > > Thus static becomes dynamic!
> > > 
> > > And, by the way, this is a problem: if we have a library
> > > which does the above, and we repeatedly load it and unload
> > > it while using the mutex in between, it will leak.
> > 
> > As you pointed out, if dlopen()/dlclose() are called repeatedly,
> > handle leak might occur even if pthread_mutex_t is statically
> > allocated.
> 
> Cygwin 3.5 is due really soon now, so we can't change anything here,
> except fixing the pthread_once problem (@takashi, didn't you want to
> apply your patch?)
> 
> As for the next major release, do we have a chance to revamp
> pthread_mutex_t so that it does NOT dynamically create an OS synch
> object?  Is there a way we can change the really much too complex
> pthreads code to simplify things and use, say, SRWLOCKs, or any other
> synch mechanism which is faster and less intrusive?
> 
> The biggest problem, IMHO, is the DREADED fact that the original author
> of the pthreads code defined the exposed pthread types as, for instance,
> 
>   typedef struct __pthread_mutex_t {char __dummy;} *pthread_mutex_t;
> 
> So they only take 1 byte in user space and there's no chance to fit
> an SRWLOCK or, FWIW, a LONG value in there to be used with Interlocked
> functions.  That's really a problem we're kind of stuck with, I fear.

No, wait, I'm an idiot.  The types are defined as *pointers*, so
they have a size of 8 bytes in user code.  That means we should
be able to implement this differently, less dynamic, and still
be able to do it backward compatible.

We *really should try that and simplifying things at the same time.

Is anybody willing to give this a whirl?  We have a good year until
the next major release...


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: Possiblly bug of cygwin1.dll

[Corinna Vinschen via Cygwin]

On Jan 24 20:55, Takashi Yano via Cygwin wrote:
> On Mon, 22 Jan 2024 19:24:52 -0800
> Kaz Kylheku wrote:
> > In real systems, the static distinction has no meaning.
> > 
> > This code can be inside a shared library:
> > 
> >static pthread_mutex_t g_lock = PTHREAD_MUTEX_INITIALIZER;
> > 
> > this library could be loaded by dlopen and unloaded with dlclose.
> > Thus static becomes dynamic!
> > 
> > And, by the way, this is a problem: if we have a library
> > which does the above, and we repeatedly load it and unload
> > it while using the mutex in between, it will leak.
> 
> As you pointed out, if dlopen()/dlclose() are called repeatedly,
> handle leak might occur even if pthread_mutex_t is statically
> allocated.

Cygwin 3.5 is due really soon now, so we can't change anything here,
except fixing the pthread_once problem (@takashi, didn't you want to
apply your patch?)

As for the next major release, do we have a chance to revamp
pthread_mutex_t so that it does NOT dynamically create an OS synch
object?  Is there a way we can change the really much too complex
pthreads code to simplify things and use, say, SRWLOCKs, or any other
synch mechanism which is faster and less intrusive?

The biggest problem, IMHO, is the DREADED fact that the original author
of the pthreads code defined the exposed pthread types as, for instance,

  typedef struct __pthread_mutex_t {char __dummy;} *pthread_mutex_t;

So they only take 1 byte in user space and there's no chance to fit
an SRWLOCK or, FWIW, a LONG value in there to be used with Interlocked
functions.  That's really a problem we're kind of stuck with, I fear.


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: Add ability to hide non-standard itoa/utoa() in stdlib.h ?

[Corinna Vinschen via Cygwin]

On Jan 22 16:47, Christian Franke via Cygwin wrote:
> Busybox does not build OOTB on Cygwin due to the addition of itoa/utoa() to
> newlib in 2014:
> https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=32c96dd
> 
> This is because Busybox use local functions with same name but different
> signature. This does not affect build on FreeBSD, Linux (glibc, musl libc),
> ... because these functions simply do not exits there. For the busybox
> Cygwin package, I use an ugly local hack to fix this.
> 
> itoa() is mentioned as a non-standard extension here:
> https://en.wikibooks.org/wiki/C_Programming/stdlib.h/itoa
> https://cplusplus.com/reference/cstdlib/itoa/
> 
> MSVC provides itoa() as a "POSIX version" of _itoa():
> https://learn.microsoft.com/cpp/c-runtime-library/reference/itoa-itow
> 
> But SUS-1997... POSIX-2018 do not mention these functions:
> https://pubs.opengroup.org/onlinepubs/7908799/
> https://pubs.opengroup.org/onlinepubs/9699919799/
> 
> Newlib guards the prototypes with __MISC_VISIBLE in stdlib.h and
> sys/features.h says:
> 
>  * __MISC_VISIBLE
>  *  Extensions found in both BSD and SVr4 (shorthand for
>  *  (__BSD_VISIBLE || __SVID_VISIBLE)), or newlib-specific
>  *  extensions; enabled by default.
> 
> __MISC_VISIBLE is set if and only if _DEFAULT_SOURCE is set, so the comment
> below should also include "... or newlib-specific extensions":
> 
>  * _DEFAULT_SOURCE (or none of the above)
>  *     POSIX-1.2008 with BSD and SVr4 extensions
> 
> 
> The above is not suitable to disable only the non-standard functions for
> such use cases. Using -D_GNU_SOURCE should IMO not enable functions
> unavailable on Linux. This is not the case because _GNU_SOURCE implies
> _DEFAULT_SOURCE.
> 
> No patch provided for now, as I'm not yet sure how to handle this. Possibly:
> 
> - Use __MISC_VISIBLE only for (__BSD_VISIBLE || __SVID_VISIBLE) - under the
> assumption that this is applicable for most cases.
> - Introduce __NONSTD_VISIBLE for non-standard functions like itoa().
> - Introduce _NONSTD_SOURCE to set __NONSTD_VISIBLE independent from other
> _*_SOURCE defines.

Counter proposal:

First of all, Cygwin does NOT export itoa/utoa!  Only the prototypes
exist from the Cygwin POV.

As Cygwin is usually the only newlib project with backward compat
issues, we have two simple choices:

- Drop itoa/utoa entirely, or
- just guard them with

#if __MISC_VISIBLE && !defined (__CYGWIN__)

You can make a proposal like that on the newlib list and then we can
discuss it there, ok?


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: Possiblly bug of cygwin1.dll

[Corinna Vinschen via Cygwin]

On Jan 22 13:41, ASSI via Cygwin wrote:
> Corinna Vinschen via Cygwin writes:
> > However, I don't find this in the standards.  pthread_once is neither
> > one of the required cancellation points, nor one of the optional
> > cancellation points.
> 
> The initializer can be cancellable per POSIX, though:
> 
> "The pthread_once() function is not a cancellation point. However, if
> init_routine is a cancellation point and is canceled, the effect on
> once_control shall be as if pthread_once() was never called."

I didn't test that, but that should be automatically correct, the
way cancellation works in 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