On Sat, 2 Aug 2025, ASSI via Cygwin wrote:
> Jeremy Drake via Cygwin writes:
> > 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 _ZdlP
On Sat, 2 Aug 2025, Takashi Yano via Cygwin wrote:
> On Fri, 1 Aug 2025 15:34:16 +
> "Old, Oliver" wrote:
> > > >echo-win32.exe C:\"Program Files"\
> > > echo-win32.exe
> > > C:"Program
> > > Files\
> > >
> > > Is this as you expected?
> > >
> > > >echo.exe C:\"Program Files"\
> > > echo
> > >
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 the rmdir fails)
call getcwd
fail the test if it doesn't get an
On Tue, 29 Jul 2025, Cedric Blancher via Cygwin wrote:
> Good moring!
>
> Could the posix_spawn() work (branch heads/topic/posix_spawn) be
> merged now, but the new version kept off by default unless an option
> in the CYGWIN env var is set?
>
> That would make testing IMO much easier...
It coul
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 2025, Corinna Vinschen via Cygwin wrote:
> > > > Unless there's so
On Tue, 29 Jul 2025, Jon Turney via Cygwin wrote:
> Unfortunately, setup doesn't know how to process standalone packages.
>
> Your options are described at:
>
> https://cygwin.com/packaging-contributors-guide.html#installing
>
>
> Yes, this all terrible :( . Someone should make it work better...
>
On Tue, 29 Jul 2025, Corinna Vinschen via Cygwin wrote:
> 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 o
On Mon, 28 Jul 2025, Corinna Vinschen via Cygwin wrote:
> 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++ n
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 the wrapper for delete was not being called. This was
> > because del
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 the wrapper for delete was not being called. This was
> > because del
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 in the GCC spec, and is not part of the
per_process_cxx
On Sat, 7 Jun 2025, kikairoya via Cygwin wrote:
> Dear Cygwin team,
>
> I’ve found that rebase.exe makes certain assumptions that do not conform
> to the PE specification.
>
> 1. Incorrect handling of COFF File Header position
> When checking the 'Characteristics' field in the COFF File Header,
>
On Wed, 2 Jul 2025, Corinna Vinschen via Cygwin wrote:
> 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?
GitHub Actions.
https://github.com/jeremyd2019/cygwin/actions
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 3221225477]
[Thread 25728.0x33c0 exited with code 322122
On Tue, 1 Jul 2025, Brian Inglis via Cygwin wrote:
> On 2025-06-30 13:07, Jeremy Drake via Cygwin wrote:
> > On Mon, 30 Jun 2025, Corinna Vinschen via Cygwin wrote:
> >
> >> Off the top of my head I don't know how to check the pgid already exists.
> >> Do you
I cannot duplicate this failure locally, but in GHA the following test
case fails with
Process group 0 != expected 704
child exited with code 1
FAIL winsup.api/spawnpgid.exe (exit status: 1)
I suspect there must be a race between the child process calling getpgid
and the parent running "vchild->p
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 required to be returned by the POSIX docs in
> > https://pubs.opengroup.org/
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 allows any arbitrary positive integer to
be set as pgid, rathe
I've been poking around in child_info_spawn lately, and I've noticed
commit 8d8724ee1b5aa6a1b080c76a0dec3678136d4981 ("Cygwin: pty: Fix Ctrl-C
handling further for non-cygwin apps.") added the following (it's since
been revised to an InterlockedOr, but that's not relevant to my question):
if
On Fri, 27 Jun 2025, Corinna Vinschen via Cygwin wrote:
> 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;
On Sun, 22 Jun 2025, Daisuke Fujimura via Cygwin wrote:
> The reproduction procedure could be simplified.
>
> A segmentation fault (SIGSEGV) occurs when running a Ruby script using
> Ruby 3.4.2 (test package) on Cygwin 3.6.3-1 (x86_64), where Thread.new
> is used to require 'openssl' inside a thre
On Fri, 20 Jun 2025, Sebastian Feld via Cygwin wrote:
> Does anyone have ideas for a better powershell<-->Cygwin integration?
> What features are missing, how could both sides better interact with each
> other?
Perhaps you would like MSYS2 - it is Cygwin, but with patches to try to
make it integ
On Wed, 18 Jun 2025, Jeremy Drake via Cygwin wrote:
> The "stress tests x86_64 on arm64 Windows" tests "fp" and "memcpy" seem to
> be consitently failing since 364226a. The step is allowed to continue on
> error because there is some flakiness with tests o
The "stress tests x86_64 on arm64 Windows" tests "fp" and "memcpy" seem to
be consitently failing since 364226a. The step is allowed to continue on
error because there is some flakiness with tests on arm64 Windows, but
these tests seem to be pretty consistently failing.
It seems like 3 commits we
On Tue, 17 Jun 2025, Radek Barton via Cygwin wrote:
> Hello Sebastian.
>
> AFAIK, LLVM has no *-pc-cygwin targets support and there is no-one trying to
> change that.
We're working on that. LLVM 21.x should be much better in that regard.
There has been no effort towards aarch64-pc-cygwin though
On Tue, 17 Jun 2025, Sebastian Feld via Cygwin wrote:
> Now that Microsoft is porting Cygwin to Aarch64:
>
> Do you know how to run Windows Aarch64 in qemu, so people can test
> Cygwin Aarch64 changes?
>
> Sebi
Yes, but as others have said it is too slow to really be practical.
What I've done la
On Sat, 14 Jun 2025, Jeremy Drake via Cygwin wrote:
> Consider the following -std=c++20:
> #include
>
> constinit pthread_mutex_t foo = PTHREAD_MUTEX_INITIALIZER;
>
> With g++ 12.4.0, this succeeds, but with clang 20.1.6 it fails:
> pthreadtest.cpp:3:27: error: variable doe
Consider the following -std=c++20:
#include
constinit pthread_mutex_t foo = PTHREAD_MUTEX_INITIALIZER;
With g++ 12.4.0, this succeeds, but with clang 20.1.6 it fails:
pthreadtest.cpp:3:27: error: variable does not have a constant initializer
3 | constinit pthread_mutex_t foo = PTHREAD_MUTEX_
On Fri, 13 Jun 2025, Jeremy Drake wrote:
> I am working on some posix_spawn tests for the new stc repository [1], and
> making sure they behave the same between Cygwin and Linux. I found one
> case (so far) which does not: passing NULL for argument "envp" to
> posix_spawn.
>
> In Cygwin, this res
I am working on some posix_spawn tests for the new stc repository [1], and
making sure they behave the same between Cygwin and Linux. I found one
case (so far) which does not: passing NULL for argument "envp" to
posix_spawn.
In Cygwin, this results in the child inheriting the environment from the
On Wed, 11 Jun 2025, Jeremy Drake via Cygwin wrote:
> While making some tests for a path parser in rust
> (https://github.com/rust-lang/rust/pull/141864), an interesting corner
> case in Cygwin path handling came to light:
>
> Works:
> \\.\C:
> //.\C:
> //./C:\foo
&
On Thu, 12 Jun 2025, Sam Edge via Cygwin wrote:
> I would think that if you're building something against Cygwin, it's probably
> best to assume it's POSIX where only forward-slash is special and not try to
> second-guess.
This is unsafe, and actually where the rust PR started out. If you only
t
While making some tests for a path parser in rust
(https://github.com/rust-lang/rust/pull/141864), an interesting corner
case in Cygwin path handling came to light:
Works:
\\.\C:
//.\C:
//./C:\foo
Doesn't work:
//./C:
//./C:/foo
It appears to be able to use the \\.\ prefix, there must be at leas
On Sun, 8 Jun 2025, Brian Inglis via Cygwin wrote:
> On 2025-06-07 19:50, Jeremy Drake via Cygwin wrote:
> > On Sun, 8 Jun 2025, Roland Mainz via Cygwin wrote:
> >
> >> I know... but the request is for portable applications and scripts,
> >> which either use |pat
On Sun, 8 Jun 2025, Roland Mainz via Cygwin wrote:
> I know... but the request is for portable applications and scripts,
> which either use |pathconf(...,_PC_CASE_SENSITIVE)| or /bin/getconf to
> probe this information. Both APIs are not supported by Cygwin yet...
Isn't it?
https://github.com/cy
I noticed while looking at JIT test failures in LLVM that they don't have
an implementation for Cygwin for flushing the instruction cache. I don't
see any Cygwin function calling FlushInstructionCache, is there some
POSIXy function for this? I don't really want to have to include Windows
headers
On Wed, 4 Jun 2025, Don Slutz via Cygwin wrote:
> Using 3.6.1-1 works fine. I am very sure this is based on the same issue that
> others have reported.
>
> looks like the key in that I get for "getent passwd $(id -u)":
>
> NASUNI+dslutz:*:4096:4096:U-NASUNI\dslutz,S-1-12-1-3596282818-121614275
On Tue, 3 Jun 2025, Jeremy Drake via Cygwin wrote:
> On Sun, 1 Jun 2025, Jon Turney wrote:
>
> > On 25/05/2025 17:53, Jeremy Drake via Cygwin wrote:
> > > On Sun, 25 May 2025, ASSI via Cygwin wrote:
> > >
> > > > Jeremy Drake via Cygwin writes:
> &
On Sun, 1 Jun 2025, Jon Turney wrote:
> On 25/05/2025 17:53, Jeremy Drake via Cygwin wrote:
> > On Sun, 25 May 2025, ASSI via Cygwin wrote:
> >
> > > Jeremy Drake via Cygwin writes:
> > > > Apparently the fix that MSYS2 made for openssl in
> > > > h
In https://github.com/rust-lang/rust/pull/141864 I was going to say that
passing an already-posix path through cygwin_conv_path(CPP_WIN_A_TO_POSIX,
...) was unsafe because Windows ANSI file paths are either CP_ACP or
CP_OEMCP, while Cygwin POSIX path encodings are based on the C locale
encoding (us
On Sun, 25 May 2025, Brian Inglis via Cygwin wrote:
> On 2025-05-25 12:30, Jeremy Drake wrote:
> > Cargo issue (manifests as a hang, but running under gdb shows a SIGSEGV)
> > still reproduces without the curl patch :(
>
> Could you please post the gdb backtrace and build details or sufficient inf
On Sun, 25 May 2025, Brian Inglis via Cygwin wrote:
> So please try installing the relevant Cygwin/Mingw64 OpenSSL test packages,
> with
> the latest curl packages, retest and report, if you don't mind.
Cargo issue (manifests as a hang, but running under gdb shows a SIGSEGV)
still reproduces with
On Sun, 25 May 2025, Brian Inglis via Cygwin wrote:
> So please try installing the relevant Cygwin/Mingw64 OpenSSL test packages,
> with
> the latest curl packages, retest and report, if you don't mind.
>
I've got 'dist' tarballs built for Cygwin, in
https://github.com/jeremyd2019/rust/releases/t
On Sun, 25 May 2025, ASSI via Cygwin wrote:
> Jeremy Drake via Cygwin writes:
> > Apparently the fix that MSYS2 made for openssl in
> > https://github.com/msys2/MSYS2-packages/pull/3448 is also not present in
> > Cygwin, so cargo continues to crash after I patched li
On Sat, 24 May 2025, Jeremy Drake via Cygwin wrote:
> I'm trying to get rust and cargo working on Cygwin (as github user
> @Berrysoft is getting it going on MSYS2), and I wanted to direct the curl
> maintainer's attention to https://github.com/curl/curl/issues/17262. I am
>
I'm trying to get rust and cargo working on Cygwin (as github user
@Berrysoft is getting it going on MSYS2), and I wanted to direct the curl
maintainer's attention to https://github.com/curl/curl/issues/17262. I am
hitting this now with cargo on Cygwin with curl 8.13.0-1. There was a
workaround a
On Fri, 23 May 2025, Yuyi Wang wrote:
> On Fri, 23 May 2025, Jeremy Drake wrote:
> > Maybe. MSYS2 doesn't generally advise to rebase on x86_64, but I think
> > Cygwin does as part of its setup/postinstall hooks. As a hack, I was able
> > to work around this by setting the "dynamicbase" flag on t
On Fri, 23 May 2025, Yuyi Wang wrote:
> On Wed, 22 May 2025, Jeremy Drake wrote:
> > Ultimately, playing whack-a-mole in a 64-bit address space hoping that the
> > DLL will load in the same place as the parent is an exercise in futility,
> > especially in only 6 attempts.
>
> Outside cygwin, rustc
On Wed, 21 May 2025, Jeremy Drake via Cygwin wrote:
> On Wed, 21 May 2025, Jeremy Drake via Cygwin wrote:
>
> > the child to not be very fruitful, but maybe there's some debugging to be
> > done there
>
> Well, found the bug that results in a 0 size. size is a
On Wed, 21 May 2025, Jeremy Drake via Cygwin wrote:
> the child to not be very fruitful, but maybe there's some debugging to be
> done there
Well, found the bug that results in a 0 size. size is a DWORD, but
mb.RegionSize is 0x2. mb.RegionSize is SIZE_T, but I figur
On Tue, 20 May 2025, Yuyi Wang wrote:
> Thank you for your reply. The DLL is a "proc macro" DLL for rustc, which means
> that it's not designed to be changed after created. However, I've also found
> that this stage-1 compiler doesn't always trigger this failure: it just
> trigger
> fork failure
On Mon, 19 May 2025, Yuyi Wang via Cygwin wrote:
> Recently I'm trying to build rustc on Cygwin (actually MSYS2). Here is the
> error:
>
> 0 [main] rustc 3299 child_info_fork::abort: couldn't allocate memory
> 0x1FD10(0) for
> '\??\D:\Straw\Documents\Git\rust\build\x86_64-pc-cygwin\st
On Sat, 3 May 2025, Brian Inglis via Cygwin wrote:
> On 2025-05-03 12:21, Roland Mainz via Cygwin wrote:
> > Is it somehow possible that the CI+Release binaries (*.exe, *.dll) can
> > be signed with signtool
> > (https://learn.microsoft.com/en-us/windows/win32/seccrypto/signtool)?
>
> No - would b
On Mon, 28 Apr 2025, Jeremy Drake via Cygwin wrote:
> I was just describing cygwin_conv_path on a rust issue
> (https://github.com/rust-lang/backtrace-rs/pull/704). I was saying that
> the pointer `to` is not accessed when `size` is 0, but it turns out on
> circa line 4022 in pa
I was just describing cygwin_conv_path on a rust issue
(https://github.com/rust-lang/backtrace-rs/pull/704). I was saying that
the pointer `to` is not accessed when `size` is 0, but it turns out on
circa line 4022 in path.cc
to = (void *) wcpcpy ((wchar_t *) to, ro_u_globalroot.Buffer);
This is
On Sun, 27 Apr 2025, David Christensen wrote:
> On 4/27/25 14:59, Jeremy Drake wrote:
> > On Sun, 27 Apr 2025, Jeremy Drake via Cygwin wrote:
> > > Does sshfs.exe have any exports? Should it?
>
>
> Thank you for the reply.
>
>
> I do not know how to ans
On Sun, 27 Apr 2025, Jeremy Drake via Cygwin wrote:
> On Sun, 27 Apr 2025, David Christensen via Cygwin wrote:
>
> > The procedure entry point cygfuse_report could not be
> > located in the dynamic link library C:\cygwin64\sshfs.exe.
> > -> OK
>
> Does sshfs
I was asked an interesting question on a github issue about rust
backtraces: is there an API in Cygwin to get a list of loaded modules? I
know the info is there in the dlls list, but I don't see an API to get at
it.
The question was in regards to whether rust should be using toolhelp32 on
Cygwin
On Sun, 27 Apr 2025, David Christensen via Cygwin wrote:
> The procedure entry point cygfuse_report could not be
> located in the dynamic link library C:\cygwin64\sshfs.exe.
> -> OK
Does sshfs.exe have any exports? Should it?
(It is legal for an exe to have exports, and for a DLL to reference t
On Sun, 20 Apr 2025, Takashi Yano via Cygwin wrote:
> Is there any other blocker to build Rust for cygwin?
https://github.com/rust-lang/rust/issues/137819
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwi
On Sun, 20 Apr 2025, Takashi Yano via Cygwin wrote:
> On Mon, 24 Mar 2025 14:41:19 +0800
> Yuyi Wang wrote:
> > > I mean it is some kind of cross compiler.
> >
> > Yes. Rustc is a cross compiler powered by LLVM.
> >
> > > ...is it possible to build Rust compiler itself by the cross-compiler?
> >
>
On Mon, 14 Apr 2025, Bruno Haible via Cygwin wrote:
> Especially since this commit modified select.cc, removing a comment
> /* TODO: Buffer really full or non-Cygwin reader? */
> and here we are exactly in that case: a non-Cygwin process reading from
> Cygwin's /dev/null.
That's Cygwin's select
On Fri, 11 Apr 2025, Andrey Repin via Cygwin wrote:
> Though, I'm using takecommand's free runtime (TCC-RT), which has an explicit
> START /ELEVATED command, and I'm using a wrapper for such tasks.
cygutils'
cygstart -a runas /bin/bash ... ?
--
Problem reports: https://cygwin.com/problems.
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
> > at_quick_exit or pthread_atfork callbacks from the DSO being unloaded.
> >
> > https://sourcewar
On Thu, 10 Apr 2025, Takashi Yano via Cygwin wrote:
> On Wed, 9 Apr 2025 16:41:18 -0700 (PDT)
> Jeremy Drake wrote:
> > I've been doing some building with cmake 4.0.0 and ninja 1.12.1 (of
> > llvm/clang, we've got something that seems to mostly work for a cygwin
> > target), and I'm noticing after
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 pthread_atfork handlers remin
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 pthread_atfork handlers reminded me of a scenario
> > that I know glibc handles, but it seems that Cygwin
I've been doing some building with cmake 4.0.0 and ninja 1.12.1 (of
llvm/clang, we've got something that seems to mostly work for a cygwin
target), and I'm noticing after updating to 3.6.1 it no longer seems to
cancel the build when I hit Ctrl-C (previously I was still on 3.5 due to
the cmake/ninja
The recent issue with pthread_atfork handlers reminded me of a scenario
that I know glibc handles, but it seems that Cygwin does not. Test case:
== test.c ==
#include
#include
#include
#include
typedef void(*func_type)(void);
int main(void)
{
int wstatus = 0;
func_type func = NULL;
vo
On Sat, 5 Apr 2025, Jon Turney wrote:
> On 05/04/2025 06:28, Jeremy Drake via Cygwin wrote:
> > I just happened to look at dlfcn.cc dladdr function, and I had a question.
> > Should dladdr be using the GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT
> > flag? It doesn't
I just happened to look at dlfcn.cc dladdr function, and I had a question.
Should dladdr be using the GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT
flag? It doesn't seem like dladdr should be incrementing the refcount.
--
Problem reports: https://cygwin.com/problems.html
FAQ:
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
> > patch (preferred) or at least info how to distinguish in
> > fs_info::update(*) between the MSFT d
On Thu, 3 Apr 2025, Takashi Yano via Cygwin wrote:
> It seems that raw_write() is called before returning from
> pthread::atforkchild() in fork::child().
>
> Moving _my_tls.fixup_after_fork() before atforkchild() seems
> to solve the issue.
>
> What about:
> ld_preload ();
> fixup_hooks_after_fork
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, command was:
> /usr/bin/cmake.exe -E env VERBOSE=1 /usr/bin/make.e
On Mon, 31 Mar 2025, Corinna Vinschen via Cygwin wrote:
> On Mar 30 14:02, Jeremy Drake via Cygwin wrote:
> > I kind of think
> > https://github.com/Kitware/CMake/blob/5978c57c20b762a5aeb4b00f31a51a090d670430/Utilities/cmcurl/CMakeLists.txt#L165
> > should match "^(Lin
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
> function ‘weak_random’:
> /home/WDAGUtilityA
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
function ‘weak_random’:
/home/WDAGUtilityAccount/cmake-4.0.0/Utilities/cmcurl/lib/rand.c:124:21:
error: implicit declaration of fu
On Sat, 29 Mar 2025, Soren via Cygwin wrote:
> I'll add a bit more information in hopes that we can still find a fix. This
> Windows 10 laptop goes into "sleep mode" after a couple hours of no
> keyboard or mouse input, and when it does so sshd disconnects any sessions.
>
> Also, I remember hearin
On Tue, 4 Mar 2025, Cedric Blancher via Cygwin wrote:
> Good evening!
>
> Is IO_REPARSE_TAG_LX_SYMLINK supported in Cygwin 3.3?
>
> Ced
Use the Source, Luke
https://sourceware.org/cgit/newlib-cygwin/tree/winsup/cygwin/path.cc?h=cygwin-3_3-branch#n2625
(that's the reading part, the making part i
On Fri, 21 Feb 2025, Jeremy Drake via Cygwin wrote:
> I rebased msys2's msys2-runtime fork of cygwin on top of cygwin's master
> branch, and then rebased git-for-windows' msys2-runtime on top of THAT.
>
> 1. Git for Windows's test suite still passes with that (wh
b,
newline, hash, backslash) are now escaped within records as octal \NNN.
In the below snippet, I only convert to delimited by \0 *after*
unescaping, when spaces or newlines may be present in the entries.
> On Sun, Mar 2, 2025 at 10:57 PM Jeremy Drake via Cygwin
> wrote:
>
> > #
On Sun, 2 Mar 2025, Jeremy Drake via Cygwin wrote:
> > 2) assuming there is not, I want to make a script using only things
> > present in a "base system" to clean them up.
>
> Now that the mount points are escaped and contain the Windows volume roots
> starting
On Mon, 3 Jun 2024, Jeremy Drake via Cygwin wrote:
> I'm not necessarily sure that the subject is clear enough, so I want to be
> explicit that I'm talking about files (or I guess potentially directories,
> though I've never seen that) generated by the `try_to_bin` fun
On Thu, 27 Feb 2025, Jan Nijtmans via Cygwin wrote:
> Hi all,
>
> I'll try to find time to update this, in the coming weeks. The problem is
> that
> sqlite for cygwin has some cygwin-specific changes, which were never
> accepted upstream. So it's not trivial to do that. An additional problem
> is
On Tue, 25 Feb 2025, Takeshi Nishimura via Cygwin wrote:
> No, it's beegfs.sys you install.
> SMB is not used, it uses its own protocol. If you do a
> FileRemoteProtocolInfo query the protocol field says it's a
> WNNC_NET_RDR2SAMPLE.
Always nice when a driver doesn't change "sample" idenfiers. I
On Tue, 25 Feb 2025, Cedric Blancher via Cygwin wrote:
> WebDAV and BeeGFS are not alone, the Windows ms-nfs41-client and
> ms-nfs42-client ALWAYS (even with default NFSv4.1 port TCP/2049) use
> UNC paths with "@" character, like
> \\stripe02.zebracluster.intra.pasteur.fr@2049\nfs4\disk02\
> OpenT
On Sat, 22 Feb 2025, Corinna Vinschen via Cygwin wrote:
> On Feb 21 14:35, Jeremy Drake via Cygwin wrote:
> > 2. This seems to have fixed a severe performance regression in Curl's test
> > suite (https://github.com/curl/curl/pull/16217) that I was recently
> > looking
I rebased msys2's msys2-runtime fork of cygwin on top of cygwin's master
branch, and then rebased git-for-windows' msys2-runtime on top of THAT.
1. Git for Windows's test suite still passes with that (which is nice, it
tended to hang when we did this with 3.5.5).
2. This seems to have fixed a sev
On Thu, 20 Feb 2025, Roland Mainz via Cygwin wrote:
> > > Same happens with dash and ksh93.
>
> And THAT statement is BAD, because it means basic shell functionality
> is broken, affecting dash/bash/ksh93 - reading that IMO means Cygwin
> has a problem in the pipe/fifo code... ;-(
>
> Best way for
On Tue, 18 Feb 2025, Corinna Vinschen via Cygwin wrote:
> On Feb 18 11:19, Jeremy Drake via Cygwin wrote:
> > On Tue, 18 Feb 2025, Corinna Vinschen via Cygwin wrote:
> >
> > > Yep. Are you going to create a patch?
> >
> > I'm not seeing a parti
On Tue, 18 Feb 2025, Corinna Vinschen via Cygwin wrote:
> Yep. Are you going to create a patch?
I'm not seeing a particularly clean way to do this. Bring back
available_drives, mask off bits when we see the corresponding drive root
from dos_drive_mappings, and return those drive letters whose bi
On Tue, 18 Feb 2025, Cedric Blancher via Cygwin wrote:
> Good evening!
>
> Cygwin 3.6.0-0.374.g4dd859d01c22.x86_64 on Win10/AMD64/64bit:
>
> df -k no longer shows the data of SMB filesystems, e.g. mount points
> N:-Z: are mounted, but df -k shows nothing:
Ugh, do we have to somehow union volume m
On Mon, 17 Feb 2025, Corinna Vinschen wrote:
> The requirements of posix_spawn and their helper functions are so
> that we can't easily fulfill them without doing the fork/exec
> twist.
>
> See https://man7.org/linux/man-pages/man3/posix_spawn.3.html.
> Windows CreateProcess() is not quite the sam
On Mon, 17 Feb 2025, Corinna Vinschen via Cygwin wrote:
> In fact, I can reproduce this occassionally back to 3.5.0 and back to
> OpenSSH 9.7p1. We can't easily try this with older Cygwin versions.
> It's getting increasingly hard to build older Cygwin versions due to
> compiler dependencies and
On Sat, 8 Feb 2025, Corinna Vinschen via Cygwin wrote:
> Go for it. There's already matching logic in fhandler/proc.cc,
> function format_proc_partitions() for the "win-mounts" column
> of /proc/partitions. Probably this can be reused.
Actually closer to the dos_drive_mappings at the end of mou
On Fri, 7 Feb 2025, Roland Mainz via Cygwin wrote:
> Hi!
>
>
>
> [Slightly offtopic, but I am banging my head against this problem most
> of the day]
> What symlink value should |MRxCreate()| return on |STATUS_REPARSE| to
> redirect to another DOS drive or UNC path ? I tried something like
>
On Fri, 7 Feb 2025, Corinna Vinschen via Cygwin wrote:
> On Feb 6 13:31, Jeremy Drake via Cygwin wrote:
> > Now that my patch to escape characters in /proc/mounts has been applied,
> > I'll get back to what I was thinking about back in June. I would like to
> > have a
Now that my patch to escape characters in /proc/mounts has been applied,
I'll get back to what I was thinking about back in June. I would like to
have a way to list Windows volume roots in Cygwin, and it seems to make
sense to me to expose them via getmntent, /proc/mounts, etc. The way I
see this
We were attempting to build util-linux 2.40.2 for MSYS2, based on the
source package of util-linux-2.40.2-2 from Cygwin [1]. We were scratching
our heads as to why it wasn't building tasksel for us, when it did in your
package. I evenutally saw in the cygport that it tests for sys/syscall.h
and w
On Tue, 4 Feb 2025, Roland Mainz via Cygwin wrote:
> it seems that Cygwin does not support |IO_REPARSE_TAG_MOUNTPOINT| for
> "remote" filesystems:
> snip
> 2582/* Don't handle junctions on remote filesystems as
> symlinks. This type
> 2583 of reparse point is handl
1 - 100 of 156 matches
Mail list logo
