Re: new c++ new/delete overloads need wrapping?

On Jul 29 14:34, Jeremy Drake via Cygwin wrote: > On Tue, 29 Jul 2025, Jeremy Drake via Cygwin wrote: > > > On Tue, 29 Jul 2025, Corinna Vinschen via Cygwin wrote: > > > > > On Jul 28 12:57, Jeremy Drake via Cygwin wrote: > > > > On Mon, 28 Jul

Re: getcwd() and ENOENT

On Jul 29 16:22, Jeremy Drake via Cygwin wrote: > I have been looking at test failures in LLVM, and I've come across a > strange one (to me). It appears to be failing because it expects to: > > create a temp directory > chdir to the temp directory > rmdir the temp directory > (skip the test if th

Re: new c++ new/delete overloads need wrapping?

On Jul 28 12:57, Jeremy Drake via Cygwin wrote: > On Mon, 28 Jul 2025, Corinna Vinschen via Cygwin wrote: > > Unless there's some automatism referencing the __wrap_X functions even > > if the --wrap option isn't present, I don't see this incompatibility as > >

Re: new c++ new/delete overloads need wrapping?

On Jul 25 11:05, Jeremy Drake via Cygwin wrote: > On Fri, 25 Jul 2025, Corinna Vinschen via Cygwin wrote: > > > On Jul 24 22:41, Jeremy Drake via Cygwin wrote: > > > I was looking into C++ new/delete --wrap linker options, and noticed that > > > in a quick test

Re: new c++ new/delete overloads need wrapping?

On Jul 25 10:28, Jeremy Drake via Cygwin wrote: > On Fri, 25 Jul 2025, Corinna Vinschen via Cygwin wrote: > > Nevertheless, the code overriding the members in per_process_cxx_malloc > > is living in the app (_cygwin_crt0_common.cc). If you just append members > > to per_p

Re: new c++ new/delete overloads need wrapping?

On Jul 24 22:41, Jeremy Drake via Cygwin wrote: > I was looking into C++ new/delete --wrap linker options, and noticed that > in a quick test the wrapper for delete was not being called. This was > because delete is being compiled to _ZdlPvm and that symbol is not present > in the --wrap arguments

Re: Language used by setup-x86_64.exe

On Jul 24 20:12, Jon Turney via Cygwin wrote: > On 23/07/2025 09:25, Takashi Yano via Cygwin wrote: > > On Wed, 23 Jul 2025 17:02:22 +0900 > > Takashi Yano wrote: > > > Recent cygwin setup-x86_64.exe has Japanese translation and > > > it uses Japanese when it is running in Japanese Windows. > > >

Re: readdir() returns inaccessible name if file was created with invalid UTF-8

On Jul 24 19:45, Thomas Wolff via Cygwin wrote: > Am 24.07.2025 um 17:35 schrieb Corinna Vinschen: > > Consider the following GB18030 string: 0x90 0x30 0x81 0x30 > > > > This string translates into a UTF-16 surrogate pair: 0xd800 0xdc00. > > > > If you run a tweaked version of your test applicato

Re: readdir() returns inaccessible name if file was created with invalid UTF-8

On Jul 24 09:28, Brian Inglis via Cygwin wrote: > On 2025-07-24 04:30, Corinna Vinschen via Cygwin wrote: > > Or shall simply go along with CESU-8 when converting back to multibyte > > to keep the string the same as with wcstombs? > > There are 15 * SMP as BMP characters, so

Re: readdir() returns inaccessible name if file was created with invalid UTF-8

Thomas, On Jul 23 05:44, Thomas Wolff via Cygwin wrote: > > > Am 22.07.2025 um 15:05 schrieb Corinna Vinschen: > > > > mbrtowc() is inherently a bad idea when it comes to UTF-16. It's a > > > > function which only works really correctly for the unicode base plane, > > > > or if wchar_t is big enou

Re: readdir() returns inaccessible name if file was created with invalid UTF-8

On Jul 24 15:41, Thomas Wolff via Cygwin wrote: > Am 24.07.2025 um 12:30 schrieb Corinna Vinschen: > > What does that mean? Consider this UTF8 input string: > > > >0xf0 0x90 0x80 0x2e > > > >mbstowcs: returns -1 > >sys_mbstowcs: f0f0 f090 f080 002e > > > > Let's convert it back

Re: readdir() returns inaccessible name if file was created with invalid UTF-8

Hi Thomas, hi Christian, On Jul 23 17:50, Thomas Wolff via Cygwin wrote: > Am 23.07.2025 um 09:53 schrieb Corinna Vinschen via Cygwin: > > On Jul 23 05:44, Thomas Wolff via Cygwin wrote: > > What bugs me is that we have the choice between a broken mbrtowc on > > one side and

Re: readdir() returns inaccessible name if file was created with invalid UTF-8

On Jul 23 05:44, Thomas Wolff via Cygwin wrote: > OK, suppose I'd consider to switch to mbs[[n]r]towcs, collecting bytes until > the function gives me a result. > This would work fine as long as I receive only valid sequences. But look at > input string test case > char nonbmp[] = {0xF8, 0x88, 0x8A

Re: readdir() returns inaccessible name if file was created with invalid UTF-8

On Jul 22 05:38, Thomas Wolff via Cygwin wrote: > Am 27.06.2025 um 12:30 schrieb Corinna Vinschen via Cygwin: > > On Jun 26 19:07, Christian Franke via Cygwin wrote: > > > With some trial and error I found a testcase for this more serious problem > > > reported yes

Re: Calling system() in multi-threads.

On Jul 18 22:32, Takashi Yano via Cygwin wrote: > I embedded debug code into mm/cygheap.cc, that is: > > diff --git a/winsup/cygwin/mm/cygheap.cc b/winsup/cygwin/mm/cygheap.cc > index 338886468..bab4067e0 100644 > --- a/winsup/cygwin/mm/cygheap.cc > +++ b/winsup/cygwin/mm/cygheap.cc > @@ -371,7 +3

Re: Calling system() in multi-threads.

On Jul 18 17:41, Takashi Yano via Cygwin wrote: > On Fri, 18 Jul 2025 09:51:11 +0200 > Corinna Vinschen via Cygwin wrote: > > Yes, that's what I meant with my above paragraph, i.e. > > > > > > > > I checked the sources and I don't see any depe

Re: sys/termios.h defines struct winsize after it is referenced in function signatures

Hi Zachary, thanks for the report. I pushed a patch. This will show up in the next Cygwin release 3.6.5. https://sourceware.org/cgit/newlib-cygwin/commit/?id=73600d68227e Thanks, Corinna On Jul 18 00:02, Zachary Santer via Cygwin wrote: > Was "MacOS Homebrew bash '5.3.0(1)-release' breaks '

Re: Calling system() in multi-threads.

On Jul 18 00:32, Takashi Yano via Cygwin wrote: > On Thu, 17 Jul 2025 23:14:21 +0900 > Takashi Yano wrote: > > As a starting point, I tried tntroducing locking. It almost works > > as expected, however, sometimes my STC in my first report is hangs > > if N is large e.g. 100. The patch is as attache

Re: Calling system() in multi-threads.

On Jul 18 01:28, Takashi Yano via Cygwin wrote: > On Fri, 18 Jul 2025 00:44:46 +0900 > Takashi Yano wrote: > > On Thu, 17 Jul 2025 17:19:49 +0200 > > Corinna Vinschen wrote: > > > On Jul 17 23:14, Takashi Yano via Cygwin wrote: > > > > Hi Corinna, > > > > > > > > On Wed, 16 Jul 2025 17:36:42 +0200

Re: Calling system() in multi-threads.

On Jul 18 00:44, Takashi Yano via Cygwin wrote: > On Thu, 17 Jul 2025 17:19:49 +0200 > Corinna Vinschen wrote: > > On Jul 17 23:14, Takashi Yano via Cygwin wrote: > > > Hi Corinna, > > > > > > On Wed, 16 Jul 2025 17:36:42 +0200 > > > Corinna Vinschen wrote: > > > > On Jul 16 23:52, Takashi Yano vi

Re: Calling system() in multi-threads.

On Jul 17 23:14, Takashi Yano via Cygwin wrote: > Hi Corinna, > > On Wed, 16 Jul 2025 17:36:42 +0200 > Corinna Vinschen wrote: > > On Jul 16 23:52, Takashi Yano via Cygwin wrote: > > > Do you have any idea? > > > > Locking would be super-simple. > > > > But theoretically it should be possible to

Re: Calling system() in multi-threads.

On Jul 16 23:52, Takashi Yano via Cygwin wrote: > Hi Corinna, > > On Wed, 18 Jun 2025 20:31:27 +0900 > Takashi Yano wrote: > > On Tue, 17 Jun 2025 15:42:26 -0700 > > Mark Geisert wrote: > > > Hi Takashi, > > > > > > On 6/17/2025 5:54 AM, Takashi Yano via Cygwin wrote: > > > > Hi, > > > > > > > >

Re: doxygen hangs when many call graphs are generated.

On Jul 16 22:45, Takashi Yano via Cygwin wrote: > On Wed, 16 Jul 2025 21:36:04 +0900 > Takashi Yano via Cygwin wrote: > > On Wed, 16 Jul 2025 21:13:59 +0900 > > Takashi Yano via Cygwin wrote: > > > > > On Tue, 17 Jun 2025 21:46:47 +0900 > > > Takashi Yano wrote: > > > > I encountered a problem o

Re: rmdir of non empty dir causes wrong errno with SMB or NFS fs

Hi Aurélien, On Jul 12 15:02, Aurélien Couderc wrote: > Cygwin 3.7.0-0.219.gbf81e32f29e0.x86_64, /bin/rmdir causes wrong errno > if the filesystem is SMB or NFS. > > Test case: > bash -c 'rm -Rf d1 ; mkdir d1 ; touch d1/f1 ; rmdir d1' > > On C; I get: > rmdir: failed to remove 'd1': Directory no

Re: setfacl -m g:None:rwx nfstmp1 not working for dirs in Cygwin 3.6.3 Re: /usr/bin/setfacl is broken in 3.7.0-0.127.g2029784e05d9

On Jul 8 20:16, Lionel Cons via Cygwin wrote: > This is still broken in Cygwin 3.6.3, and blocks the update to that version: > > $ cd "$PWD" # plain NTFS filesystem > $ uname -a > CYGWIN_NT-10.0-19045 halcyonrenard17 3.6.3-1.x86_64 2025-06-05 11:45 > UTC x86_64 Cygwin > $ mkdir nfstmp1 > $ setfac

Re: Segfault if /proc/PID/maps is opened in parallel threads [CAUSE: RtlQueryProcessDebugInformation]

On Jul 5 19:34, Christian Franke via Cygwin wrote: > Corinna Vinschen via Cygwin wrote: > > I just added two patches, one of them dropping > > RtlQueryProcessDebugInformation > > in favor of EnumProcessModules in dlsym(), the other by adding a global > > mutex t

Re: Segfault if /proc/PID/maps is opened in parallel threads [CAUSE: RtlQueryProcessDebugInformation]

On Jul 2 18:28, Corinna Vinschen via Cygwin wrote: > On Jul 2 16:18, Christian Franke via Cygwin wrote: > > On Tue, 27 May 2025 17:44:10 +0200 Christian Franke wrote: > > > On Sun, 25 May 2025 16:46:49 +0200, Christian Franke wrote: > > > > On Sat, 24 May 2025 15

Re: Segfault if /proc/PID/maps is opened in parallel threads [CAUSE: RtlQueryProcessDebugInformation]

On Jul 2 16:18, Christian Franke via Cygwin wrote: > On Tue, 27 May 2025 17:44:10 +0200 Christian Franke wrote: > > On Sun, 25 May 2025 16:46:49 +0200, Christian Franke wrote: > > > On Sat, 24 May 2025 15:19:10 +0200, Christian Franke wrote: > > > > If /proc/PID/maps is opened in parallel threads,

Re: possible race initializing pgid in spawned child

On Jun 30 16:47, Jeremy Drake via Cygwin wrote: > I cannot duplicate this failure locally, but in GHA the following test > case fails with GHA? Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.c

Re: issues debugging crash in cygwin dll with gdb

On Jul 1 16:14, Jeremy Drake via Cygwin wrote: > I had an issue in some code I was working on in Cygwin, which resulted in > a segfault in the Cygwin dll. It did not work out well though, the > process exited with code 0. Attempting to debug with gdb gave > [Thread 25728.0x6e60 exited with code

Re: setpgid non-compliance with POSIX?

On Jun 30 12:07, Jeremy Drake via Cygwin wrote: > On Mon, 30 Jun 2025, Corinna Vinschen via Cygwin wrote: > > > On Jun 28 12:32, Jeremy Drake via Cygwin wrote: > > > I was looking at setpgid yesterday, and it seems deficient with respect to > > > the errors requir

Re: setpgid non-compliance with POSIX?

On Jun 28 12:32, Jeremy Drake via Cygwin wrote: > I was looking at setpgid yesterday, and it seems deficient with respect to > the errors required to be returned by the POSIX docs in > https://pubs.opengroup.org/onlinepubs/9799919799/functions/setpgid.html > > Basically, it seems that setpgid allo

Re: XSAVE-related segfaults observed under wine

Hi Pip, On Jun 27 14:41, Pip Cet via Cygwin wrote: > My suggested fix is to align the value in %rbx to the next 64-byte > multiple after the "cpuid" instruction is executed, by performing the > assembler equivalent of $rbx += 63; $rbx &= -64; I tried this: > > diff --git a/winsup/cygwin/scripts/g

Re: readdir() returns inaccessible name if file was created with invalid UTF-8

On Jun 27 15:32, Christian Franke via Cygwin wrote: > $ touch $'t-\xef\x80\x80' > The name mapping is: > "t-\xEF\x80\x80" -(open, ...)-> L"t-\xDB59" -(readdir)-> "t-" Did you copy/paste this from the old mail, by any chance? Using the latest test DLL the mapping is "t-\xEF\x80\x80" -(open, ...

Re: readdir() returns inaccessible name if file was created with invalid UTF-8

Hi Christian, On Jun 26 19:07, Christian Franke via Cygwin wrote: > Corinna Vinschen via Cygwin wrote: > > On Jun 25 16:59, Christian Franke via Cygwin wrote: > > > On Sun, 15 Sep 2024 19:47:11 +0200, Christian Franke wrote: > > > > If a file name contains an inva

Re: readdir() returns inaccessible name if file was created with invalid UTF-8

On Jun 25 16:59, Christian Franke via Cygwin wrote: > On Sun, 15 Sep 2024 19:47:11 +0200, Christian Franke wrote: > > If a file name contains an invalid (truncated) UTF-8 sequence, open() > > does not refuse to create the file. Later readdir() returns a different > > name which could not be used to

Re: symlink_native() bug with case-sensitive file-systems Re: [PATCH] symlink_native: allow linking to `..`

On Jun 23 20:22, Sebastian Feld wrote: > On Mon, Jun 23, 2025 at 10:52 AM Corinna Vinschen > wrote: > > > > On Jun 20 13:33, Sebastian Feld wrote: > > > On Fri, Jun 20, 2025 at 12:03 PM Johannes Schindelin > > > wrote: > > > > winsup/cygwin/path.cc | 21 - > > > > 1 file chan

Re: symlink_native() bug with case-sensitive file-systems Re: [PATCH] symlink_native: allow linking to `..`

On Jun 20 13:33, Sebastian Feld wrote: > On Fri, Jun 20, 2025 at 12:03 PM Johannes Schindelin > wrote: > > winsup/cygwin/path.cc | 21 - > > 1 file changed, 16 insertions(+), 5 deletions(-) > > > > diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc > > index 42919a7cf5

Re: [PATCH][API-CONFORMAANCE] Increase SYMLOOP_MAX to 63

Hi Sebastian, On Jun 17 09:48, Sebastian Feld wrote: > The following patch increases from 10 to 63, per Windows spec > https://learn.microsoft.com/en-us/windows/win32/fileio/reparse-points > > Security impact is minor, SYMLOOP_MAX is just an artificial limiter to > prevent endless loops. In case

Re: On dropping Capability SIDs

On Apr 10 19:29, Lluís Batlle i Rossell via Cygwin wrote: > On Thu, Apr 10, 2025 at 12:17:13PM +0200, Corinna Vinschen wrote: > > I pushed a patch which skips not only Capability SIDs, but also AzureAD > > SIDs, IIS APPPOOL SIDs and Samba-generated SIDs. > > https://sourceware.org/cgit/newlib-cygwi

Re: pthread_atfork vs dlopen/dlclose

On Apr 10 11:03, Jeremy Drake via Cygwin wrote: > On Thu, 10 Apr 2025, Corinna Vinschen via Cygwin wrote: > > > > It seems glibc takes care of this implicit deregistration in > > > __cxa_finalize, after calling __cxa_atexit functions, it unregisters any > > >

Re: On dropping Capability SIDs

Hi Lluís, On Apr 10 09:52, Lluís Batlle i Rossell via Cygwin wrote: > Hello, > > I saw this change to cygwin to ignore S-1-15-3-* SIDs: > https://www.cygwin.com/cgit/newlib-cygwin/commit/?id=271f187b7b59a6645e24e9c36b60ba31f6527556 > > I think, though, that the current code doesn't completely sk

Re: pthread_atfork vs dlopen/dlclose

On Apr 9 23:32, Jeremy Drake via Cygwin wrote: > On Wed, 9 Apr 2025, Jeremy Drake via Cygwin wrote: > > > On Thu, 10 Apr 2025, Kevin Schnitzius via Cygwin wrote: > > > > > On Wednesday, April 9, 2025 at 06:54:34 PM EDT, Jeremy Drake via Cygwin > > > wrote: > > > > > > > The recent issue with pt

Re: symbolic link curiousity in 3.6.0

Hi Bruno, On Mar 29 15:02, Bruno Haible via Cygwin wrote: > Corinna Vinschen wrote: > > > Regarding what acl_extended_file() does, there is the man page by > > > Andreas Grünbacher: > > > https://www.kernel.org/doc/man-pages/online/pages/man3/acl_extended_file.3.html > > > Gnulib is not the only u

Re: ftruncate() may fail with EISDIR if other process calls open()

On Apr 8 17:07, Christian Franke via Cygwin wrote: > Corinna Vinschen via Cygwin wrote: > > On Apr 8 13:50, Corinna Vinschen via Cygwin wrote: > > > On Apr 7 09:59, Christian Franke via Cygwin wrote: > > > > Found because 'stress-ng --fcntl 2 --verify'

Re: ftruncate() may fail with EISDIR if other process calls open()

On Apr 8 13:50, Corinna Vinschen via Cygwin wrote: > On Apr 7 09:59, Christian Franke via Cygwin wrote: > > Found because 'stress-ng --fcntl 2 --verify' reports "ftruncate failed, > > errno=21": > > Thanks for the testcase. I know what happens. Stay

Re: ftruncate() may fail with EISDIR if other process calls open()

On Apr 7 09:59, Christian Franke via Cygwin wrote: > Found because 'stress-ng --fcntl 2 --verify' reports "ftruncate failed, > errno=21": Thanks for the testcase. I know what happens. Stay tuned for a patch. Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ:

Re: Cygwin SSHD session unable to access cloud/OneDrive files

On Apr 4 16:23, Shaddy Baddah via Cygwin wrote: > > On 4/04/2025 10:02 am, Shaddy Baddah via Cygwin wrote: > > Hi, > > > > On 4/04/2025 4:49 am, ASSI via Cygwin wrote: > > > Shaddy Baddah via Cygwin writes: > > > > If I connect an SSH session via the "native" OpenSSH instance > > > > integrated

Re: unix socket hang when connect

On Apr 7 12:35, Christian Franke via Cygwin wrote: > Yuyi Wang via Cygwin wrote: > > Thank you Christian, setting SO_PEERCRED on the client socket works. It's a > > little wierd, though. Is it OK to always set it to NULL on a unix socket? > > No, this is a Cygwin extension, originally added for p

Re: Windows Remote Driver Identification Re: Cygwin wishlist for NFSv4.2 driver?

On Apr 3 14:28, Jeremy Drake via Cygwin wrote: > On Wed, 2 Apr 2025, Cedric Blancher via Cygwin wrote: > > > On Tue, 1 Apr 2025 at 13:54, Corinna Vinschen via Cygwin > > wrote: > > > No, but if we want to *better* support this driver, we need either a > > >

Re: Crashes in cmake subprocesses since 3.6.0

Hi Takashi, On Apr 3 01:52, Takashi Yano via Cygwin wrote: > > Currently, I am looking into this problem. > > > > What I noticed so far is: > > * The problem occurs after the commit 7ed9adb356df. > > * This problem is happen when fhandler_fifo_pipe::raw_write() returns > > error because cygwai

Re: symbolic link curiousity in 3.6.0

On Apr 1 15:32, Paul Eggert via Cygwin wrote: > > > traditionally (and I'm talking about 7th edition Unix) a single > > > output line of 'ls' corresponded to a state obtained atomically from the > > > file system. I realize we can't always do that nowadays but the further we > > > depart from it,

Re: Cygwin wishlist for NFSv4.2 driver? Re: [Ms-nfs41-client-devel] ANN: NFSv4.2/NFSv4.1 filesystem client Windows driver binaries for Windows 10/11+WindowsServer 2019/2022 for testing, 2025-03-31 ...

On Apr 1 12:27, Cedric Blancher via Cygwin wrote: > On Tue, 1 Apr 2025 at 09:46, Cedric Blancher > wrote: > > > > Good morning! > > > > For your consideration - we need FEEDBACK, please! > > > > New is: > > - 2nd Spring-Release (🐝) > > - Improved Windows Extended Attribute (EA) support > > - Spa

Re: acl man pages {and others?} (Was: symbolic link curiosity in 3.6.0)

On Mar 31 23:26, Brian Inglis via Cygwin wrote: > On 2025-03-31 12:49, Corinna Vinschen via Cygwin wrote: > > On Mar 31 12:35, Brian Inglis via Cygwin wrote: > [...] > > > Has anyone a feel if there are any other projects on that list whose man > > > pages would be u

Re: acl man pages {and others?} (Was: symbolic link curiosity in 3.6.0)

On Mar 31 12:35, Brian Inglis via Cygwin wrote: > On 2025-03-29 13:08, Alejandro Colomar wrote: > > On Sat, Mar 29, 2025 at 07:45:27PM +0100, Alejandro Colomar wrote: > > > Hi Bruno, > > > > Oops, s/Bruno/Brian/ :) > > > > > > > > On Sat, Mar 29, 2025 at 12:28:52PM -0600, Brian Inglis wrote: >

Re: symbolic link curiousity in 3.6.0

On Mar 31 12:12, Paul Eggert via Cygwin wrote: > On 3/31/25 11:27, Pádraig Brady wrote: > > The file could be deleted at any time. > > We're just suppressing errors in the edge case it's deleted > > More generally, though, the file could be renamed and another put in its > place, which means that

Re: Terminate handler not called for C++ Cygwin programs on Windows 11

Hi Jörg, On Mar 31 09:00, Joerg Markus (LBC) via Cygwin wrote: > Hi, > > a colleague and I are facing a problem with unhandled exceptions in > our C++ programs in Cygwin. The C++ standard guarantees, that > std::terminate() shall be called for thrown exceptions, that are not > caught [0]. Unfor

Re: Crashes in cmake subprocesses since 3.6.0

On Mar 30 22:58, Jeremy Drake via Cygwin wrote: > On Mon, 31 Mar 2025, Christoph Reiter via Cygwin wrote: > > > Starting with 3.6.0 when cmake calls into make/ninja/gcc there is a chance > > of > > that failing, for example like this: > > > > CMake Error: Generator: build tool execution failed, c

Re: Qt6 in Cygwin?

On Mar 31 09:14, Cedric Blancher via Cygwin wrote: > On Sun, 15 Oct 2023 at 02:14, Mark Geisert via Cygwin > wrote: > > > > Mark Geisert via Cygwin wrote: > > > > > >> Are there Qt6 - https://www.qt.io/product/qt6 - packages for Cygwin > > >> available? > > > > > > Does setup.exe show it/them as

Re: dlclose reports ENOENT with simple code

On Mar 31 11:25, Duncan Roe via Cygwin wrote: > On Sun, Mar 30, 2025 at 05:32:44PM +0800, cygwin wrote: > > Code to reproduce: > > > > > > #include > > #include > > #include > > #include > > > > int main() { > >     void* handle = dlopen("/usr/bin/cygwin1.dll", RTLD_LAZY | RTLD_LOCAL); > >    

Re: cmake 4.0.0 fails to build with cygwin 3.7.0-0.19

On Mar 30 14:02, Jeremy Drake via Cygwin wrote: > On Sun, 30 Mar 2025, Jeremy Drake via Cygwin wrote: > > > I tried to build cmake 4.0.0 with latest test gcc and cygwin packages, and > > got the following error > > > > /home/WDAGUtilityAccount/cmake-4.0.0/Utilities/cmcurl/lib/rand.c: In > > functi

[maintainer] coreutils-9.5 and 96 regression in cp (and maybe ln? mv?)

Hi Brian Regression in 9.5 and 9.6: $ ls -l /bin/setfacl* -rwxr-xr-x 1 corinna Administrators 109379 Mar 30 21:24 /bin/setfacl.exe $ cd $ ls -l x86_64-pc-cygwin/winsup/utils/setfacl* -rwxr-xr-x 1 corinna vinschen 109379 Mar 30 21:19 x86_64-pc-cygwin/winsup/utils/setfacl.exe -rw-r--r

Re: symbolic link curiousity in 3.6.0

Hi Bruno, On Mar 29 15:02, Bruno Haible via Cygwin wrote: > Corinna Vinschen wrote: > > > Regarding what acl_extended_file() does, there is the man page by > > > Andreas Grünbacher: > > > https://www.kernel.org/doc/man-pages/online/pages/man3/acl_extended_file.3.html > > > Gnulib is not the only u

Re: symbolic link curiousity in 3.6.0

Hi Paul, thanks for the patch. On Mar 29 10:31, Paul Eggert via Cygwin wrote: > On 3/29/25 04:30, Corinna Vinschen wrote: > > What it should do if only the POSIX.1e draft 17 functions are available > > is something along these lines: > > Yes, that sounds like a better approach. However, shouldn'

Re: symbolic link curiousity in 3.6.0

On Mar 29 13:12, Corinna Vinschen via Cygwin wrote: > On Mar 29 12:43, Bruno Haible via Cygwin wrote: > > OK, and what does this mean for the *files* created in such a directory? > > Just for clarity, permissions in Windows are *always* defined by an ACL. > There's no such

Re: symbolic link curiousity in 3.6.0

On Mar 29 12:58, Bruno Haible via Cygwin wrote: > Corinna Vinschen wrote: > > Btw., while I was testing test-file-has-acl.sh, I found two more bugs, > > one in test-file-has-acl.sh, and one (a problem of account handling in > > Windows) in Cygwin's setfacl(1). Together with the above change to > >

Re: symbolic link curiousity in 3.6.0

On Mar 29 12:43, Bruno Haible via Cygwin wrote: > Hi Corinna, > > > c) The expectations of test-file-has-acl.sh are wrong. > > The Cygwin-specific part of that unit test has minimal expectations: > > # Set an ACL for a group. > if setfacl -m group:0:1 tmpfile0; then > >

Re: symbolic link curiousity in 3.6.0

Hi Pádraig, thanks for your reply! On Mar 28 20:30, Pádraig Brady via Cygwin wrote: > On 28/03/2025 14:30, Bruno Haible via Gnulib discussion list wrote: > > [CCing bug-gnulib] > > > > Corinna Vinschen wrote in > > : > > Responding

Re: symbolic link curiousity in 3.6.0

Hi Bruno, thanks for your quick reply! On Mar 28 15:30, Bruno Haible via Cygwin wrote: > [CCing bug-gnulib] > > Corinna Vinschen wrote in > : > > I found the problem, it's in a gnulib header. See below. > > ... > > Gnulib's acl-inte

Re: symbolic link curiousity in 3.6.0

Hi Bruno, I found the problem, it's in a gnulib header. See below. On Mar 28 12:21, Corinna Vinschen via Cygwin wrote: > On Mar 28 10:59, Corinna Vinschen via Cygwin wrote: > > [Adding Bruno Haible] > > > > Hi Bruno, > > > > can you please take a l

Re: symbolic link curiousity in 3.6.0

On Mar 28 10:59, Corinna Vinschen via Cygwin wrote: > [Adding Bruno Haible] > > Hi Bruno, > > can you please take a look? To reiterate, with coreutils 9.6: > > $ ln -s foo bar > $ ls -l bar > ls: bar: Not supported > lrwxrwxrwx 1 corinna vinschen 3 Ma

Re: symbolic link curiousity in 3.6.0

acl_get_fd_np() and acl_get_link_np() in Cygwin? Theoretically this should fix the problem without having to fix coreutils, but I think coreutils really should take systems into account which only have the documented POSIX.1e functions. What do you think? Thanks, Corinna On Mar 27 11:49,

Re: ssh with multiplexing fails after connection and leaves zombie ssh processes

On Mar 27 16:11, Jim Garrison via Cygwin wrote: > I just learned about ssh multiplexing and tried to set it up (Cygwin client > to Debian server), but it fails to work and each attempt leaves a zombie ssh > process. > > According to the ssh -vvv debug output, authentication is successful but > the

Re: symbolic link curiousity in 3.6.0

On Mar 25 15:12, Mark Geisert via Cygwin wrote: > > > > Your ls output shows an at-sign after the name "bar". You're > > probably using an alias for ls including the -F option. Can you > > paste your alias here? > > alias ls='ls -AF --color -bv -T 0' > > The oddity occurs even if I use /bin/ls

Re: symbolic link curiousity in 3.6.0

On Mar 25 02:25, Mark Geisert via Cygwin wrote: > This occurs on the released 3.6.0 but not in 3.6.0 test build 327. > > /tmp ls foo bar > ls: cannot access 'foo': No such file or directory > ls: cannot access 'bar': No such file or directory > > /tmp ln -s foo bar > > /tmp ls foo bar > ls: cann

Re: two bugs in getlocalename_l

Hi Bruno, On Mar 24 18:12, Corinna Vinschen via Cygwin wrote: > On Mar 24 14:12, Bruno Haible via Cygwin wrote: > > Hi, > > > > It's good to see the addition of getlocalename_l from POSIX [1] in Cygwin > > 3.6.0. > > > > [1] > > https://

Re: two bugs in getlocalename_l

On Mar 24 14:12, Bruno Haible via Cygwin wrote: > Hi, > > It's good to see the addition of getlocalename_l from POSIX [1] in Cygwin > 3.6.0. > > [1] > https://pubs.opengroup.org/onlinepubs/9799919799/functions/getlocalename_l.html > > However, there are two bugs: > > > - "If > the val

Re: Document support for @ character in UNC paths

On Mar 19 04:31, Takeshi Nishimura via Cygwin wrote: > On Tue, Mar 18, 2025 at 8:19 PM Corinna Vinschen via Cygwin > wrote: > > > > On Mar 18 15:57, Takeshi Nishimura via Cygwin wrote: > > > On Tue, Feb 25, 2025 at 4:59 PM Takeshi Nishimura > > > wrote:

Re: Document support for @ character in UNC paths

On Mar 18 15:57, Takeshi Nishimura via Cygwin wrote: > On Tue, Feb 25, 2025 at 4:59 PM Takeshi Nishimura > wrote: > > > > Subject says it all, please document that @ characters in UNC paths > > are now supported, for WebDAV and BeeGFS > > Was this ever added to the Cygwin documentation for Cygwin

Re: Integrating Cygwin into ReactOS (UNIX services for ReactOS)?

On Mar 17 22:20, Dan Shelton via Cygwin wrote: > Hello! > > Mad? idea: > Would there be any objections if Cygwin would be integrated into > ReactOS, and always shipped as part of ReactOS? As long as you adhere to the license, feel free. But it doesn't make sense to me. A Unix service in the usu

Re: cygwin-devel vs libbsd-devel: arc4random_stir() macro in stdlib.h breaks bsd/stdlib.h

On Mar 14 17:12, Corinna Vinschen via Cygwin wrote: > On Mar 14 16:50, Corinna Vinschen via Cygwin wrote: > > On Mar 14 13:48, Christian Franke via Cygwin wrote: > > > $ nm /usr/lib/libbsd.dll.a | grep ' arc4random' || echo not found > >

Re: cygwin-devel vs libbsd-devel: arc4random_stir() macro in stdlib.h breaks bsd/stdlib.h

On Mar 14 16:50, Corinna Vinschen via Cygwin wrote: > On Mar 14 13:48, Christian Franke via Cygwin wrote: > > $ nm /usr/lib/libbsd.dll.a | grep ' arc4random' || echo not found > > not found > > > > I guess: > > - arc4random_addrandom() should be remo

Re: cygwin-devel vs libbsd-devel: arc4random_stir() macro in stdlib.h breaks bsd/stdlib.h

On Mar 14 13:48, Christian Franke via Cygwin wrote: > Corinna Vinschen via Cygwin wrote: > > On Mar 13 08:59, Christian Franke via Cygwin wrote: > > > Problem introduced in a8891c93: > > > > > > $ cygcheck -f /usr/include/stdlib.h > >

Re: cygwin 3.6.0: No signals received after swapcontext() is used

On Mar 14 21:52, Takashi Yano via Cygwin wrote: > On Fri, 14 Mar 2025 13:19:28 +0100 > Corinna Vinschen wrote: > > On Mar 14 20:35, Takashi Yano via Cygwin wrote: > > > On Fri, 14 Mar 2025 11:01:25 +0100 > > > Corinna Vinschen wrote: > > > > I don't think so. I was mulling in circles over this ton

Re: cygwin 3.6.0: No signals received after swapcontext() is used

On Mar 14 20:35, Takashi Yano via Cygwin wrote: > On Fri, 14 Mar 2025 11:01:25 +0100 > Corinna Vinschen wrote: > > I don't think so. I was mulling in circles over this tonight > > (don't ask me how I slept!) and came to the same conclusion. > > But here's the problem: > > > > I'm simply not 100%

Re: cygwin 3.6.0: No signals received after swapcontext() is used

On Mar 14 12:56, Takashi Yano via Cygwin wrote: > On Fri, 14 Mar 2025 08:12:36 +0900 > Takashi Yano wrote: > > On Thu, 13 Mar 2025 23:46:49 +0100 > > Corinna Vinschen wrote: > > > I have a slighty changed version. This one treats anything other > > > than 0, 1 or 2 new addresses on the stack as bug

Re: cygwin 3.6.0: No signals received after swapcontext() is used

On Mar 13 17:30, Corinna Vinschen via Cygwin wrote: > On Mar 13 21:31, Takashi Yano via Cygwin wrote: > > What about following patch instead of your sigdelayed patch? > > [...] > > @@ -1834,6 +1841,26 @@ _cygtls::call_signal_handler () > >signal handler. *

Re: cygwin-devel vs libbsd-devel: arc4random_stir() macro in stdlib.h breaks bsd/stdlib.h

On Mar 13 08:59, Christian Franke via Cygwin wrote: > Problem introduced in a8891c93: > > $ cygcheck -f /usr/include/stdlib.h > cygwin-devel-3.6.0-0.430.ga942476236b5 > > $ cygcheck -f /usr/include/bsd/stdlib.h > libbsd-devel-0.12.2-2 > > $ gcc -c -xc - <<<'#include ' > In file included from :1:

Re: cygwin 3.6.0: No signals received after swapcontext() is used

On Mar 13 21:31, Takashi Yano via Cygwin wrote: > On Thu, 13 Mar 2025 20:42:52 +0900 > Takashi Yano wrote: > > After the commit: > > > > commit a942476236b5e39bf30c533d08df7392e326a4c6 (origin/master, > > origin/main, origin/HEAD) > > Author: Corinna Vinschen > > Date: Wed Mar 12 17:17:31 2025

Re: cygwin 3.6.0: No signals received after swapcontext() is used

On Mar 12 17:06, Corinna Vinschen via Cygwin wrote: > On Mar 12 16:30, Corinna Vinschen via Cygwin wrote: > > On Mar 11 12:32, Christian Franke via Cygwin wrote: > > > The attached testcase should test the following use cases of setcontext: > > > - call from regular use

Re: cygwin 3.6.0: No signals received after swapcontext() is used

On Mar 12 16:30, Corinna Vinschen via Cygwin wrote: > On Mar 11 12:32, Christian Franke via Cygwin wrote: > > Corinna Vinschen via Cygwin wrote: > > > It's not quite clear to me why signal handling should be broken if > > > setcontext is used inside a signal h

Re: cygwin 3.6.0: No signals received after swapcontext() is used

On Mar 12 16:30, Corinna Vinschen via Cygwin wrote: > Theoretically, a small update to sigdelayed() would fix the issue: ather > then poing the original IP from the signal stack after calling the Make that: Theoretically, a small update to sigdelayed() would fix the issue: *R*ather the

Re: cygwin 3.6.0: No signals received after swapcontext() is used

On Mar 11 12:32, Christian Franke via Cygwin wrote: > Corinna Vinschen via Cygwin wrote: > > It's not quite clear to me why signal handling should be broken if > > setcontext is used inside a signal handler. The incyg flag is false > > when running the signal

Re: Chrootdirectory / Chroot - not working in OpenSSH sftp directives in \etc\sshd_config or using a custom shell script - MS OpenSSH build has a workaround

On Mar 12 06:40, Peter Board via Cygwin wrote: > Hi Cygwin Developers, > > In the source code for the session.c Cygwin is using the standard > OpenSSH source code, which checks for both the user ID of 0 and a > permissions for who can write to the new folder. > Chroot mounting test that I can't ge

Re: Cygwin 3.6 on Windows 8?

On Mar 10 20:33, Brian Inglis via Cygwin wrote: > On 2025-03-10 18:56, Dan Shelton via Cygwin wrote: > > On Mon, 10 Mar 2025 at 21:24, Brian Inglis via Cygwin wrote: > > > On 2025-03-10 04:35, Martin Wege via Cygwin wrote: > > > > On Fri, Mar 7, 2025 at 3:42 PM Dan Shelton via Cygwin wrote: > > > >

Re: Tool for listing sparse file layout

On Mar 10 21:51, Brian Inglis via Cygwin wrote: > On 2025-03-10 14:01, Corinna Vinschen via Cygwin wrote: > > On Mar 7 15:43, Cedric Blancher via Cygwin wrote: > > > On Fri, 7 Mar 2025 at 13:24, Corinna Vinschen wrote: > > > > cygutils-extra > > > Th

Re: Tool for listing sparse file layout

On Mar 7 15:43, Cedric Blancher via Cygwin wrote: > On Fri, 7 Mar 2025 at 13:24, Corinna Vinschen > wrote: > > Stop telling us what we're supposed to do for you. It's pretty > > annoying how you're exerting group pressure with (per last counting) > > five accounts to let us do your bidding on t

Re: cygwin 3.6.0: No signals received after swapcontext() is used

On Mar 8 12:07, Christian Franke via Cygwin wrote: > Corinna Vinschen via Cygwin wrote: > > On Mar 6 13:24, Christian Franke via Cygwin wrote: > > > Found because 'stress-ng --context 1 ...' always hangs. > > > > > > The attached testcase uses

Re: Tool for listing sparse file layout

[Redirected to the cygwin mailing list] Don't send unsolicited private email, use the mailing lists. On Mar 7 11:19, Cedric Blancher wrote: > Good morning! > > Corinna, > could you please add the following tool to cygwin-utils-extra package > for Cygwin 3.6? It's SUN's old utility to list the

Re: cygwin 3.6.0: No signals received after swapcontext() is used

On Mar 6 13:24, Christian Franke via Cygwin wrote: > Found because 'stress-ng --context 1 ...' always hangs. > > The attached testcase uses the example from Linux swapcontext(3) to call the > context functions. Just tested with 3.5.3 and it doesn't work there, either. So yeah, it's a bug, but i

  1   2   3   4   5   6   7   8   >