On Aug 25 23:21, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> > it is not possible to diffentiate between Cygwin
> > FIFOs and real FIFOs created from the remote side in `ls -l'
> > output.
>
> Why would that be necessary? If it's a FIFO, it can be used as a
> FIFO, regardless where a
On Aug 26 14:15, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> > This thread is not about send() blocking or returning EAGAIN. This
> > is about the behaviour of select(2) and poll(2).
>
> I was merely commenting on your note that if select() returned a socket as
> writable, and send()
On Aug 26 19:44, Martin Wege via Cygwin wrote:
> On Fri, Aug 25, 2023 at 2:19 PM Corinna Vinschen via Cygwin
> wrote:
> >
> > On Aug 23 01:05, Roland Mainz via Cygwin wrote:
> > > Note that Cygwin does not interpret the file |myfifo.fifo| as FIFO,
> > >
On Aug 27 18:13, Cary Lewis via Cygwin wrote:
> In a cygwin process that is started either from mintty or bash directly the
> following:
>
> $ user=234
>
> $ ./cat <(echo $user)
> 234
> works as expected.
>
> But after a chroot:
>From https://cygwin.com/cygwin-ug-net/highlights.html:
chroot
On Aug 28 07:35, Cedric Blancher via Cygwin wrote:
> On Sun, 27 Aug 2023 at 14:35, Corinna Vinschen via Cygwin
> wrote:
> > As for FIFOs on NFS, as I wrote, they never worked as desired on NFS.
> > For kicks I tried back until Cygwin 3.3. Given this isn't a regression,
&g
On Aug 28 12:20, Brian Inglis via Cygwin wrote:
> On 2023-08-28 05:47, Joshuah Hurst via Cygwin wrote:
> > On Mon, Aug 28, 2023 at 1:08 AM Jeremy Hetzler via Cygwin
> > wrote:
> > >
> > > On Sun, Aug 27, 2023 at 2:25 PM Ed Morton via Cygwin
> > > wrote:
> > > >
> > > > This (original email belo
On Sep 1 06:23, Cedric Blancher via Cygwin wrote:
> Good morning!
>
> During a Cygwin 3.4.8-1.x86_64 debugging session I noticed something
> odd when I looked at the network traffic generated by one of our
> cluster nodes:
> It seems that for each call to a tool (i.e. starting "sed" from
> "bash"
On Sep 8 00:14, Matthew "mirage335" Hines via Cygwin wrote:
> Really hope other Cygwin packages will not be broken because 'ARG_MAX' is
> now undefined in 'getconf' output. Caught this in a CI test for a rather
> large shell script.
>
> https://github.com/mirage335-colossus/ubiquitous_bash/blob/m
On Sep 8 06:48, Cedric Blancher via Cygwin wrote:
> On Thu, 7 Sept 2023 at 23:20, Martin Wege via Cygwin
> wrote:
> >
> > On Wed, Sep 6, 2023 at 5:27 PM Corinna Vinschen via Cygwin-announce
> > via Cygwin wrote:
> > >
> > > The following packages hav
On Sep 8 07:36, Matthew "mirage335" Hines via Cygwin wrote:
> Ok, I guess that makes sense.
>
> My worry was some './configure' script determining that the build
> environment is somehow not 'sane'. At least for the limited set of programs
> that I use under cygwin, I have set up my CI to now wat
On Sep 8 12:59, Corinna Vinschen via Cygwin wrote:
> On Sep 8 06:48, Cedric Blancher via Cygwin wrote:
> > So chmod() for a FIFO inode on NFS fails. Tested with MSFT NFSv3 and
> > new builds of the NFSv4.1 ms-nfs41-client filesystems.
>
> Did you actually test this with 3.
On Sep 8 22:31, Corinna Vinschen via Cygwin wrote:
> On Sep 8 12:59, Corinna Vinschen via Cygwin wrote:
> > On Sep 8 06:48, Cedric Blancher via Cygwin wrote:
> > > So chmod() for a FIFO inode on NFS fails. Tested with MSFT NFSv3 and
> > > new builds of the NFSv4.1
Hi Bruno,
On Oct 25 11:21, Bruno Haible via Cygwin wrote:
> Hi,
>
> Seen on
> - Cygwin 3.4.6 or 2.9.0 on x86_64.
> - Cygwin 2.9.0 on i386.
>
> According to ISO C 23 § 7.6.4.3
> "The feraiseexcept function attempts to raise the supported floating-point
>exceptions represented by its arg
[redirecting to the newlib mailing list]
This is long-standing code in newlib, not actually inside Cygwin.
On Nov 10 21:19, Bruno Haible via Cygwin wrote:
> ISO C 23 § 7.24.2.1 and 7.24.2.2 document how rand() and srand() are
> expected to behave. In particular:
> "The srand function uses the
On Nov 13 15:25, Bruno Haible wrote:
> Corinna Vinschen wrote:
> > The rand() function would still not use locking but AFAICS that's
> > not actually required by POSIX or ISO C.
>
> Correct. Those who want an MT-safe rand-like function need to use random(),
> not rand().
FTR, we have to differ he
Hi Bruno,
On Nov 10 17:19, Bruno Haible via Cygwin wrote:
> The function 'random' is, unlike 'rand', not marked as not MT-safe in POSIX
> [1][2]. Thus it must be multithread-safe [3]:
> "Each function defined in the System Interfaces volume of POSIX.1-2017
>is thread-safe unless explicitly s
On Nov 13 15:38, Corinna Vinschen wrote:
> On Nov 13 15:25, Bruno Haible wrote:
> > Corinna Vinschen wrote:
> > > The rand() function would still not use locking but AFAICS that's
> > > not actually required by POSIX or ISO C.
> >
> > Correct. Those who want an MT-safe rand-like function need to u
On Nov 13 19:04, Bruno Haible via Cygwin wrote:
> Corinna Vinschen wrote:
> > > And indeed glibc, musl libc, AIX, Android, and even NetBSD implement it
> > > in a
> > > multithread-safe way.
> >
> > Our code is from FreeBSD, originally. I checked the latest code from
> > FreeBSD. It doesn't loc
Hi Bruno,
On Nov 13 22:33, Bruno Haible via Cygwin wrote:
> Corinna Vinschen wrote:
> > https://pubs.opengroup.org/onlinepubs/9699919799/functions/rand.html
> > [...]
> > With regard to rand(), there are two different behaviors that may be
> > wanted in a multi-threaded program:
> >
> > 1.
On Nov 13 17:14, Glenn Strauss wrote:
> On Mon, Nov 13, 2023 at 10:33:48PM +0100, Bruno Haible via Cygwin wrote:
> > POSIX does not have these two sentences, but instead has:
> >
> > "The rand() function need not be thread-safe."
>
> I read the above as requiring *reentrancy*, but not *thread-s
On Nov 14 12:52, Bruno Haible wrote:
> Corinna Vinschen wrote:
> > > My understanding of this paragraph is:
> > > - If an application wants 1., they can use rand_r with SEED pointing
> > > to a global variable.
> > > - If an application wants 2., they can use rand_r with SEED pointing
> > >
On Nov 17 06:54, Thomas Wolff via Cygwin wrote:
>
>
> Am 16.11.2023 um 21:30 schrieb Brian Inglis via Cygwin:
> > On 2023-11-16 11:55, matthew patton via Cygwin wrote:
> > > On Thursday, November 16, 2023 at 03:50:24 AM EST, Andrey Repin wrote:
> > > > > Does Cygwin have a command line tool (Scri
On Nov 22 23:52, Cedric Blancher via Cygwin wrote:
> On Tue, 26 Sept 2023 at 07:15, Cedric Blancher
> wrote:
> >
> > Good morning!
> >
> > Does Cygwin support something like Linux binfmt, to register new binary
> > types?
> >
> > Goal would be to recognise python compiled code, or
> > https://wik
On Nov 22 23:44, Cedric Blancher via Cygwin wrote:
> On Wed, 22 Nov 2023 at 17:15, Eliot Moss via Cygwin wrote:
> >
> > On 11/22/2023 10:43 AM, Bill Stewart via Cygwin wrote:
> > > On Wed, Nov 22, 2023 at 7:53 AM Jose Isaias Cabrera wrote:
> > >
> > > I have a new Win11 PC, and I wanted to capture
On Nov 23 00:25, Cedric Blancher via Cygwin wrote:
> Good morning!
>
> How can I set the localisation locale of Windows netstat cmd from
> Cygwin? LC_ALL=C does not help, a French or German Windows will use
> French or German language still
Cygwin has no influence on how non-Cygwin tools are doin
On Nov 23 23:36, Cedric Blancher via Cygwin wrote:
> Linux has fallocate(fd, FALLOC_FL_PUNCH_HOLE|FALLOC_FL_KEEP_SIZE, ...)
> to punch a hole into a file, i.e. deallocate the blocks given and make
> the file a "sparse file".
We don't support the Linux-specific fallocate(2) call, only ftruncate(2)
On Nov 24 12:01, Corinna Vinschen via Cygwin wrote:
> On Nov 23 23:36, Cedric Blancher via Cygwin wrote:
> > Linux has fallocate(fd, FALLOC_FL_PUNCH_HOLE|FALLOC_FL_KEEP_SIZE, ...)
> > to punch a hole into a file, i.e. deallocate the blocks given and make
> > the file a "s
On Nov 30 04:44, Martin Wege via Cygwin wrote:
> Hello,
>
> does Cygwin have UNC path conversion functions, for example UNC path
> to DOS mount letter, UNC path to file URL?
Neither Cygwin nor Windows really care for that when using paths.
Either you use a drive letter or you use an UNC path, and
On Nov 30 04:53, Martin Wege via Cygwin wrote:
> Hello,
>
> if I do a mount -o bind //foo/bar/baz /mnt the UNC path //foo/bar/baz
> is evaluated immediately, i.e. the network share //foo/bar/baz is
> "mounted" immediately.
>
> Is it possible to mount //foo/bar/baz only the first time someone does
On Nov 30 04:55, Martin Wege via Cygwin wrote:
> Hello,
>
> Does Cygwin have tools (modified /usr/bin/dd ?) to read/write NTFS
> alternate data streams?
No. As you know, the colon is translated to a normal filename
character, and there's no POSIX-like API to expose ADS raw to user
space.
There
On Dec 1 04:55, Andrey Repin via Cygwin wrote:
> Greetings, Martin Wege!
>
> > Cygwin mount(1) is (per docs) limited to 64 mounts. Why was that
> > limitation chosen, and does it apply even if I create bind mounts to
> > UNC paths (not DOS letters)? DOS letters might be restricted by the
> > ASC
On Dec 1 11:12, Cedric Blancher via Cygwin wrote:
> Good morning!
>
> Small comment about 3.5.0 commit "Cygwin: sparse support: enable
> automatic sparsifying of files on SSDs"
> https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=832e91422c4ae9b2dcd0c307779f3dd53ee9c0ac
>
> Can this function
On Dec 1 11:22, Cedric Blancher via Cygwin wrote:
> I see the value of 128k (128*1024 bytes) quite often in your sparse
> file commits.
Yes, but they have been removed. Read the patches again, especially commit
65831f88d6c4.
> Can you please make this value a per filesystem tunable?
No, becaus
On Dec 3 17:45, Cedric Blancher via Cygwin wrote:
> Good evening!
>
> What is the maximum path length and path element (single file, dirname
> length) in Win32 API,
https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation
> Cygwin APIs on Windows 11,
NAME_MAX is 255
On Dec 5 07:36, Thomas Wolff via Cygwin wrote:
>
>
> Am 01.12.2023 um 12:02 schrieb Corinna Vinschen via Cygwin:
> > On Dec 1 11:22, Cedric Blancher via Cygwin wrote:
> > > Not all filesystems have a 128k block/stripe size, and certainly most
> > > filesystem
On Dec 5 15:47, Thomas Wolff via Cygwin wrote:
>
> Am 05/12/2023 um 15:40 schrieb Thomas Wolff via Cygwin:
> > Am 05/12/2023 um 14:53 schrieb Corinna Vinschen via Cygwin:
> > > On Dec 5 07:36, Thomas Wolff via Cygwin wrote:
> > > >
> > > > Am 01.
On Dec 6 09:49, Cedric Blancher via Cygwin wrote:
> On Fri, 1 Dec 2023 at 11:43, Corinna Vinschen via Cygwin
> VMware emulates NVME SSD these days, so this should work, yes?
It doesn't matter, see below.
> Primary concern is how to detect whether sparse file support is ON in
On Dec 6 10:38, Corinna Vinschen via Cygwin wrote:
> Again, the filesystem doesn't matter. It either sets the
> FILE_SUPPORTS_SPARSE_FILES flag or not, as simple as that.
>
> If it does, you can create sparse files with chattr +S, or you can rely
> on the lseek/ftrun
On Dec 7 17:42, Shaddy Baddah via Cygwin wrote:
> Hi Corinna,
>
> On 6/12/2023 8:38 pm, Corinna Vinschen via Cygwin wrote:
>
> > If you want to see if a filesystem supports that flag, just use the
> > /usr/lib/csih/getVolInfo tool:
> >
> >$ /usr/lib/
On Dec 7 15:35, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> Hi Corinna,
>
> I have a question about this tool getVolInfo that has recently "made the
> news".
>
> Just updated my version to the latest and tried it on my drive C:, and
> specifically this is what bugs me:
>
> $ /usr
On Dec 7 18:04, Corinna Vinschen via Cygwin wrote:
> On Dec 7 15:35, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> > Hi Corinna,
> >
> > I have a question about this tool getVolInfo that has recently "made the
> > news".
> >
> > Just
On Dec 7 18:02, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> Thank you for your prompt reply!
>
> > TRIM is only enabled on a filesystem, if the underlying drive
> > actually supports TRIM. The majority of SSDs support it, but not
> > necessarily all SSDs.
> >
> > The above values,
On Dec 7 19:53, Corinna Vinschen via Cygwin wrote:
> On Dec 7 18:02, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> > Thank you for your prompt reply!
> >
> > > TRIM is only enabled on a filesystem, if the underlying drive
> > > actually supports TRIM.
On Dec 18 13:04, Cedric Blancher via Cygwin wrote:
> On Fri, 1 Sept 2023 at 13:00, Corinna Vinschen via Cygwin
> wrote:
> >
> > On Sep 1 06:23, Cedric Blancher via Cygwin wrote:
> > > Good morning!
> > >
> > > During a Cygwin 3.4.8-1.x86_64 debugging
On Dec 18 18:47, Martin Wege via Cygwin wrote:
> On Fri, Dec 1, 2023 at 10:52 AM Corinna Vinschen via Cygwin
> wrote:
> >
> > On Nov 30 04:55, Martin Wege via Cygwin wrote:
> > > Hello,
> > >
> > > Does Cygwin have tools (modified /usr/bin/dd ?) to
On Dec 18 12:10, Cedric Blancher via Cygwin wrote:
> On Wed, 6 Dec 2023 at 10:39, Corinna Vinschen via Cygwin
> wrote:
> > Basically, with 3.4, you always have to set the "sparse" mount option,
> > with 3.5, on local SSDs you don't. I don't see a problem her
On Dec 24 01:47, Roland Mainz via Cygwin wrote:
> On Thu, Dec 21, 2023 at 9:32 PM Kaz Kylheku via Cygwin
> wrote:
> > On 2023-12-21 04:16, Martin Wege via Cygwin wrote:
> > > On Wed, Dec 20, 2023 at 6:21 PM Kaz Kylheku via Cygwin
> > > wrote:
> [snip]
> > > The root cause is IMO the extra Win32 s
On Dec 20 16:32, Jim Garrison via Cygwin wrote:
> I dug around in the Cygwin doc looking for details on how /dev/random
> and /dev/urandom are implemented, but came up empty. Is this
> documented anywhere?
Not documented as such, it's a "use the source, luke" kind of
information.
/dev/random is
On Jan 8 17:11, matthew patton via Cygwin wrote:
> > For instance: Getting rid of .lnk files isn't easy with backward
> >compatibility in mind.
> screw backward compatability! :)Why carry around bandaids on bandaids
> for an OS that is 10 years out of support?
We're using .lnk files for FIFOs. T
On Jan 8 14:17, Jeffrey Altman via Cygwin wrote:
> On 1/8/2024 1:44 PM, matthew patton via Cygwin wrote:
> > > Cygwin does not create symlinks as junctions. No idea where you got that
> > > idea.
> > $ echo $CYGWINwinsymlinks:nativestrict
> > $ /usr/bin/ln -s default.GGG6q test1
> > 01/08/2024
On Jan 11 15:00, Martin Wege via Cygwin wrote:
> On Mon, Jan 8, 2024 at 3:11 PM Corinna Vinschen via Cygwin
> wrote:
> so this is IMO OK.
Yeah, but...
It's not just an open flag, it requires extending functionality of other
APIs and, for full support, tools, see
https://docs
On Jan 12 10:24, Cedric Blancher via Cygwin wrote:
> On Thu, 11 Jan 2024 at 17:41, Corinna Vinschen via Cygwin
> wrote:
> Aside from that, I volunteer with testing of O_XATTR, on demand with 1
> or 2 students too.
Yup, I'm volunteering for testing, too. Now we just have
Hi folks,
we're planning to release Cygwin 3.5 end of this month (Jan 2024) if
nothing serious crops up.
---
One major change in this release is dropping Windows 7, Windows 8,
Windows Server 2008 R2, and Windows Server 2012 fro
On Jan 17 12:27, Glenn Strauss via Cygwin wrote:
> On Wed, Jan 17, 2024 at 12:44:32PM +0100, Corinna Vinschen via Cygwin wrote:
> > Hi folks,
> >
> > we're planning to release Cygwin 3.5 end of this month (Jan 2024) if
> > nothing serious crops up.
>
>
On Jan 18 06:52, Cedric Blancher via Cygwin wrote:
> Good morning!
>
> Could Cygwin package the ms-nfs41-client (NFSv4 client with Cygwin
> support), please?
A few points:
- There is no person called "Cygwin", really. We're *all* volunteers
here. So if you want to get a certain package into
On Jan 19 22:44, Takashi Yano via Cygwin wrote:
> Hi,
>
> I might find the bug of cygwin1.dll (including 3.4.x, 3.5.0 (TEST)).
> The following test case (c++ code) causes handle leak.
>
> This issue is reproducible with both g++ and clang++.
> However, it does not happen in Linux environment.
> S
On Jan 22 12:30, Takashi Yano via Cygwin wrote:
> PATCH2: (for cygwin)
> Avoid handle leak caused when non-static pthread_once_t is initialized
> with PTHREAD_ONCE_INIT
> diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
> index 7bb4f9fc8..127569160 100644
> --- a/winsup/cygwin/thread.
On Jan 21 22:18, John Ruckstuhl via Cygwin wrote:
> I am seeing a weird phenomenon, hopefully someone can illuminate and teach.
> Or point me to an archived thread.
>
> I have some folders that Cygwin utils can readily access,
> but W10 utils claim to have no access to.
> It feels as if
> * the
On Jan 22 10:25, Corinna Vinschen via Cygwin wrote:
> On Jan 22 12:30, Takashi Yano via Cygwin wrote:
> > PATCH2: (for cygwin)
> > Avoid handle leak caused when non-static pthread_once_t is initialized
> > with PTHREAD_ONCE_INIT
> > diff --git a/winsup/cygwin/thread.c
On Jan 22 20:06, Takashi Yano via Cygwin wrote:
> On Mon, 22 Jan 2024 10:25:28 +0100
> Corinna Vinschen wrote:
> > On Jan 22 12:30, Takashi Yano via Cygwin wrote:
> > > PATCH2: (for cygwin)
> > > Avoid handle leak caused when non-static pthread_once_t is initialized
> > > with PTHREAD_ONCE_INIT
> >
On Jan 22 20:16, Takashi Yano via Cygwin wrote:
> On Mon, 22 Jan 2024 10:57:48 +0100
> Corinna Vinschen wrote:
> > On Jan 22 10:25, Corinna Vinschen via Cygwin wrote:
> > > On Jan 22 12:30, Takashi Yano via Cygwin wrote:
> > > > PATCH2: (for 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 initiali
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
> signat
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;
> >
> > th
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.
> > >
> > >
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
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
> predic
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 mentio
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
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 cas
I'm happy to announce update of the first Cygwin 3.5 release
==
IMPORTANT DEPRECATION NOTES
==
- Cygwin 3.4.10 was the LAST major vers
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 witho
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
> > >
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 th
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 b
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
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, Cor
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 argumen
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
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
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
> > S
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=0122
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/
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 c
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 LookupAcco
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
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
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
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 0x
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
>
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 #RtlGetCurre
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 availabl
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
> "Permiss
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
> (1
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
> i
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
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
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:
> > &g
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 assemb
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 th
201 - 300 of 764 matches
Mail list logo
