Hi Takashi,
On 6/1/2024 6:03 PM, Takashi Yano wrote:
Hi Ken,
On Tue, 28 May 2024 10:19:22 -0700 (PDT)
Jeremy Drake wrote:
If ldd is run against a DLL which links to the Cygwin DLL, ldh will end
up loading the Cygwin DLL dynamically, much like cygcheck or strace.
Addresses:
On 10/18/2022 11:45 AM, Corinna Vinschen wrote:
On Sep 23 11:31, Ken Brown wrote:
@@ -1043,6 +1043,8 @@ writer_shmem:
set_pipe_non_blocking (get_handle (), flags & O_NONBLOCK);
nwriters_lock ();
inc_nwriters ();
+ if (!writer_opened () )
+set_writer_opened ();
My pers
mpfd) < 0)
{
perror ("close");
exit (1);
}
FD_ZERO ();
FD_SET (fd, );
nsel = select (fd + 1, , NULL, NULL, _tm);
printf (" now select returned %d\n", nsel);
}
From f4a92734eac17dbfc7ff3541eef9611c87184ed0 Mon Sep 17 00:00:00 2001
From: Ken Brow
v2 attached with a more accurate commit message.
Ken
On 8/9/2022 3:52 PM, Ken Brown wrote:
Patch attached. Please check my changes to the commentary preceding
symlink_info::check to make sure I got it right.
I've written the patch against the master branch, but I think it should be
applied
:00:00 2001
From: Ken Brown
Date: Tue, 9 Aug 2022 15:14:07 -0400
Subject: [PATCH] Cygwin: fix return value of symlink_info::check
Currently it is possible for symlink_info::check to return -1 in case
we're searching for foo and find foo.lnk that is not a shortcut. This
contradicts the new meaning
Patch attached. I'm not 100% sure of this since it does change behavior (but in
a weird case).
KenFrom 97a2fc0d07c8f9045b73716ac5a05f972d5bd75c Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Wed, 3 Aug 2022 16:45:23 -0400
Subject: [PATCH] Cygwin: syscalls.cc: remove ".dll&
On 7/6/2022 4:25 PM, Ken Brown wrote:
Patch attached.
I wasn't sure whether the API bump was warranted for such a trivial change. But
the fact is that some programs compiled prior to the patch will behave
differently if they are recompiled after the patch. For example, emacs limits
, so this number will change when
emacs is recompiled for Cygwin 3.4.0. Is that a good enough reason to bump the API?
KenFrom 6d6c1ed356e3e8f39aa9b6447982f3fccbdabfad Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Wed, 6 Jul 2022 14:43:16 -0400
Subject: [PATCH] Cygwin: redefine some macros
On 7/4/2022 4:37 AM, Corinna Vinschen wrote:
On Jul 1 21:32, Ken Brown wrote:
I interpreted the existing comment as meaning that a decision was already
made at some point to align with Linux. But it can't hurt to wait for
Corinna to weigh in.
Personally I don't like this old crufty feature
Patch attached.From 28cd29d99fe6d1a54c8dad04854bda10743737d3 Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Sat, 2 Jul 2022 15:12:40 -0400
Subject: [PATCH] Cygwin: implement getfacl(1) for socket files
Do this by defining the acl_get method for the fhandler_socket_local
and fhandler_socket_unix
On 7/1/2022 7:31 PM, Takashi Yano wrote:
On Thu, 30 Jun 2022 21:16:35 -0400
Ken Brown wrote:
On 6/30/2022 11:45 AM, Ken Brown wrote:
On 6/27/2022 8:44 AM, Takashi Yano wrote:
- With this patch, the empty path (empty element in PATH or PATH is
absent) is treated as the current directory
On 6/30/2022 11:45 AM, Ken Brown wrote:
On 6/27/2022 8:44 AM, Takashi Yano wrote:
- With this patch, the empty path (empty element in PATH or PATH is
absent) is treated as the current directory as Linux does.
Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251730.html
It might
On 6/26/2022 9:50 PM, Takashi Yano wrote:
- poll() has a bug that it returns event which is not inquired if
events are inquired in multiple pollfd entries on the same fd at
the same time. This patch fixes the issue.
Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251732.html
On 6/27/2022 8:44 AM, Takashi Yano wrote:
- With this patch, the empty path (empty element in PATH or PATH is
absent) is treated as the current directory as Linux does.
Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251730.html
It might be a good idea to include a comment in the
On 6/11/2022 8:29 AM, Takashi Yano wrote:
On Thu, 9 Jun 2022 15:04:29 -0400
Ken Brown wrote:
OK, I'll make that change.
Isn't the _dll_crt0() code in dcrt0.cc also x86_64 specific?
Thanks for catching that. Should be fixed now.
Ken
On 6/9/2022 12:00 PM, Yaakov Selkowitz wrote:
On Thu, 2022-06-09 at 17:23 +0200, Corinna Vinschen wrote:
On May 29 17:26, Ken Brown wrote:
On 5/29/2022 9:39 AM, Jon Turney wrote:
On 26/05/2022 20:17, Ken Brown wrote:
winsup/cygwin/autoload.cc | 136
On 6/7/2022 12:49 PM, Takashi Yano wrote:
_dll_crt0() is declared as
extern void __stdcall _dll_crt0 ()
__declspec (dllimport) __attribute__ ((noreturn));
in winsup/cygwin/lib/cygwin_crt0.c, however, this patch
removes __stdcall from winsup.h and dcrt0.cc as follows.
[...]
To be consistent
On 6/5/2022 4:24 PM, Jon Turney wrote:
On 03/06/2022 15:00, Ken Brown wrote:
remove most occurrences of __stdcall, WINAPI, and __cdecl
These have no effect on x86_64. Retain only a few occurrences of
__cdecl in files imported from other sources.
While you are correct that it has no effect
On 6/5/2022 4:24 PM, Jon Turney wrote:
On 03/06/2022 15:00, Ken Brown wrote:
remove most occurrences of __stdcall, WINAPI, and __cdecl
These have no effect on x86_64. Retain only a few occurrences of
__cdecl in files imported from other sources.
While you are correct that it has no effect
Patch attached.From f3e156ec3b22e426fc79138270f6e15c8156eb7b Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Sun, 29 May 2022 18:59:55 -0400
Subject: [PATCH] Cygwin: remove most occurrences of __stdcall, WINAPI, and
__cdecl
These have no effect on x86_64. Retain only a few occurrences
On 5/29/2022 10:03 AM, Jon Turney wrote:
gdb master recently learnt how to use GetThreadDescription() [1], so set
threadnames using SetThreadDescription() [available since Windows
101607] as well.
This is superior to using a special exception to indicate the thread
name to the debugger, because
On 5/29/2022 9:39 AM, Jon Turney wrote:
On 26/05/2022 20:17, Ken Brown wrote:
winsup/cygwin/autoload.cc | 136 ---
Looks good.
I think that perhaps the stdcall decoration number n is unused on x86_64, so can
be removed also in a followup?
Thanks, I
On 5/28/2022 10:20 AM, Takashi Yano wrote:
- After the commit 6d898f43, cygwin fails to start if cygwin1.dll
is placed in the root directory. This patch fixes the issue.
Addresses: https://cygwin.com/pipermail/cygwin/2022-May/251548.html
---
winsup/cygwin/cygheap.cc | 5 +
1 file
Patch attached.From d78b3f13a5eca554d50a7c40532f84cafdd1435a Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Tue, 24 May 2022 14:26:33 -0400
Subject: [PATCH 7/7] Cygwin: remove miscellaneous 32-bit code
---
winsup/cygwin/autoload.cc| 136 ---
winsup/cygwin
Patch attached.From cfa148370cb51c6874d51ee97f79d04f6e547ca9 Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Tue, 24 May 2022 10:25:06 -0400
Subject: [PATCH 6/7] Cygwin: remove 32-bit only clipboard code
---
winsup/cygwin/fhandler_clipboard.cc | 16
winsup/cygwin/include/sys
Patch attached.From 1dd3291b22a72edc234b89e55b5bee9ebcc3f158 Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Tue, 24 May 2022 10:20:23 -0400
Subject: [PATCH 4/7] Cygwin: remove some 32-bit only path conversion functions
---
winsup/cygwin/include/sys/cygwin.h | 23 -
winsup/cygwin
Patch attached.From 2e8b069182e3ba639beac43794201e409723b5d9 Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Sun, 22 May 2022 15:18:48 -0400
Subject: [PATCH 2/7] Cygwin: simplify some function names
Remove "32" or "64" from each of the following names: acl32,
aclch
Patch attached.From 3458c48712e41cef108b7c9582fdc2f63ccac11c Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Sun, 22 May 2022 15:16:47 -0400
Subject: [PATCH 1/7] Cygwin: remove some 32-bit-only function definitions
Remove the definitions of the following: acl, aclcheck, aclfrommode,
aclfrompbits
, and it also
eliminates the need to define a prototype of stat64 for use in the build of Cygwin.
Ken Brown (7):
Cygwin: remove some 32-bit-only function definitions
Cygwin: simplify some function names
Cygwin: remove regparm.h
Cygwin: remove some 32-bit only path conversion functions
On 5/25/2022 8:30 AM, Brian Inglis wrote:
0x8008:0 EBX:31 brs AMD Branch Sampling available
0x8022:0 EAX:0 perfmon_v2 AMD ExtPerfMonAndDbg Performance Monitoring
Version 2
0x0021:0 EBX|EDX|ECX=="IntelTDX" tdx_guest Intel Trust Domain
Extensions- Guest Support
---
Patch attached. I'll push it in a few days if no one sees anything wrong with
it.
KenFrom 54cfc70ff3a548d861cb59ac6b2084cc6b791ec2 Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Sun, 22 May 2022 11:43:44 -0400
Subject: [PATCH] Cygwin: fix mknod (64-bit only)
The current definition of mknod
On 12/26/2021 6:12 PM, Ken Brown wrote:
There are some fixes (though not pipe-related) pending for 3.3.4, so I'll push
it to the 3.3 branch after I've heard from Takashi and/or Corinna.
Takashi must be unavailable also, but it's a simple enough fix that I decided to
go ahead and push
On 12/26/2021 6:23 PM, Jeremy Drake wrote:
On Sun, 26 Dec 2021, Ken Brown wrote:
On 12/26/2021 5:43 PM, Jeremy Drake wrote:
My loops are still going after an hour. I know that ARM64 would have hit
the assert before now.
Well, ARM64 hung up, but didn't hit the assert, so maybe there's some
On 12/26/2021 5:43 PM, Jeremy Drake wrote:
On Sun, 26 Dec 2021, Ken Brown wrote:
+ /* NtQueryInformationProcess can return STATUS_SUCCESS with
+invalid handle data for certain processes. See
+
https://github.com/processhacker/processhacker/blob/master/phlib
On 12/26/2021 4:35 PM, Jeremy Drake wrote:
On Sun, 26 Dec 2021, Ken Brown wrote:
On 12/26/2021 11:04 AM, Ken Brown wrote:
On 12/26/2021 10:09 AM, Ken Brown wrote:
1. For some processes, NtQueryInformationProcess(ProcessHandleInformation)
can return STATUS_SUCCESS with invalid handle
On 12/26/2021 11:04 AM, Ken Brown wrote:
On 12/26/2021 10:09 AM, Ken Brown wrote:
1. For some processes, NtQueryInformationProcess(ProcessHandleInformation) can
return STATUS_SUCCESS with invalid handle information. See the comment
starting at line 5754, where it is shown how to detect
On 12/26/2021 10:09 AM, Ken Brown wrote:
1. For some processes, NtQueryInformationProcess(ProcessHandleInformation) can
return STATUS_SUCCESS with invalid handle information. See the comment starting
at line 5754, where it is shown how to detect this.
If I'm right, the following patch should
On 12/25/2021 11:56 PM, Jeremy Drake wrote:
I set up a windows server 2022 VM last night and went nuts stressing
pacman/GPGME. I was able to reproduce the issue there:
status = 0x, phi->NumberOfHandles = 8261392, n_handle = 256
[#--] 14%
assertion
On 12/25/2021 6:00 PM, Jeremy Drake via Cygwin-patches wrote:
On Sat, 25 Dec 2021, Jeremy Drake via Cygwin-patches wrote:
On Sun, 26 Dec 2021, Takashi Yano wrote:
Could you please check the result of the following test case
in that ARM64 platform?
OK, on Windows 11 ARM64 (same machine
On 12/25/2021 2:20 PM, Jeremy Drake via Cygwin-patches wrote:
On Sun, 26 Dec 2021, Takashi Yano wrote:
Could you please check the result of the following test case
in that ARM64 platform?
I will probably not be able to get to this until tomorrow at the earliest.
But keep in mind the issue
On 12/24/2021 2:42 PM, Jeremy Drake wrote:
On Fri, 24 Dec 2021, Ken Brown wrote:
I agree that it's hard to see how the line you quoted could cause an
exception. But you were using an optimized build, so I'm not sure how
reliable the line-number information is.
Is it feasible to run your test
On 12/23/2021 7:29 PM, Jeremy Drake via Cygwin-patches wrote:
On Thu, 23 Dec 2021, Ken Brown wrote:
- for (ULONG j = 0; j < phi->NumberOfHandles; j++)
+ for (ULONG j = 0; j < min(phi->NumberOfHandles, n_handle); j++)
Reading the preceding code, I don't see how n_
On 12/23/2021 6:10 PM, Jeremy Drake via Cygwin-patches wrote:
diff --git a/winsup/cygwin/fhandler_pipe.cc
b/winsup/cygwin/fhandler_pipe.cc
index ba6b70f55..48713a38d 100644
--- a/winsup/cygwin/fhandler_pipe.cc
+++ b/winsup/cygwin/fhandler_pipe.cc
@@ -1239,7 +1239,7 @@
Patch attached. Takashi, since you wrote the analogous patch for pipes, could
you take a look?
Thanks.
KenFrom 4f47e64b11ed8d47c62fa89e9b971f44b7e9ab75 Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Tue, 23 Nov 2021 11:40:56 -0500
Subject: [PATCH] Cygwin: fhandler_fifo::raw_read: handle
Patch attached.From 6d34b62cb8e192071e193516c23419854c3b4127 Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Tue, 23 Nov 2021 10:13:43 -0500
Subject: [PATCH] Cygwin: fhandler_pipe::raw_read: fix handle leak
Slightly rearrange the code to avoid returning without closing the
event handle
On 11/17/2021 3:08 AM, Takashi Yano wrote:
- Call set_pipe_non_blocking(false) only if the pipe will be really
inherited to non-cygwin process.
LGTM, but Corinna should probably take a quick look too, since I'm not very
familiar with this part of the code.
Ken
On 11/16/2021 9:33 AM, Takashi Yano wrote:
- NtReadFile() and NtWriteFile() seems to return STATUS_PENDING
occasionally even in nonblocking mode. This patch adds handling
for STATUS_PENDING in nonblocking mode.
I haven't tested (I assume you have), but LGTM except for two typos below.
On 11/11/2021 4:47 AM, Corinna Vinschen wrote:
On Nov 10 17:22, Ken Brown wrote:
I can't immediately think of anything. But is it really impossible to phase
out DOS path support over a period of time? We could start with a HEADS-UP,
asking for comments, then a deprecation announcement
On 11/10/2021 3:32 PM, corinna-cyg...@cygwin.com wrote:
From: Corinna Vinschen
As I told Takashi in PM, I will try to more often send patches to the
cygwin-patches ML before pushing them, so there's a chance to chime in.
LGTM.
This patch series is supposed to address the `rm -rf' problem
On 10/23/2021 1:35 AM, Mark Geisert wrote:
Corinna Vinschen wrote:
Just to close this up prior to the 3.3.0 release...
Given we never actually strived for 32<->64 bit interoperability, it's
hard to argue why this should be different for the clipboard stuff.
Running 32 and 64 bit Cygwin
On 10/11/2021 2:13 AM, Mark Geisert wrote:
It's just that after submitting the patch I realized that, if we really are
going to support both Cygwin archs (x86_64 and i686), there is still the issue
of different cygcb_t layouts between Cygwin versions being ignored.
Specifically, the
On 10/9/2021 8:49 PM, Takashi Yano wrote:
- If the process having master pty opened is forked, attach_mutex
fails to be closed when master is closed. This patch fixes the
issue.
---
winsup/cygwin/fhandler_console.cc | 2 +-
winsup/cygwin/fhandler_tty.cc | 6 +++---
2 files changed,
provides it.
This struct should maybe be in sys/cygwin.h or similar, if it's expected to be
used in user-space as well.
Good idea.
On 09/10/2021 15:19, Ken Brown wrote:
On 10/8/2021 5:52 AM, Takashi Yano wrote:
How about simply just:
diff --git a/winsup/cygwin/fhandler_clipboard.cc
b/wins
On 10/8/2021 5:52 AM, Takashi Yano wrote:
How about simply just:
diff --git a/winsup/cygwin/fhandler_clipboard.cc
b/winsup/cygwin/fhandler_clipboard.cc
index ccdb295f3..d822f4fc4 100644
--- a/winsup/cygwin/fhandler_clipboard.cc
+++ b/winsup/cygwin/fhandler_clipboard.cc
@@ -28,9 +28,10 @@
On 10/8/2021 12:28 PM, Takashi Yano wrote:
- If two or more pty masters are opened in a process, closing master
causes error when closing attach_mutex. This patch fixes the issue.
Addresses:
https://cygwin.com/pipermail/cygwin-developers/2021-October/012418.html
---
Patch attached.
>From f869ec6f96e16f09be7098740bc21c0c39544fd4 Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Mon, 26 Jul 2021 10:27:53 -0400
Subject: [PATCH 2/2] Cygwin: getifaddrs: don't return a zero IPv4 address
If an interface is disconnected, net.cc:get_ifs tries to fetch IPv4
addres
Patch attached.
>From 49ff12b47d9d71960fd7b39846b302b8031affa4 Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Mon, 26 Jul 2021 08:59:09 -0400
Subject: [PATCH 1/2] Cygwin: getifaddrs: fix address family for IPv6 netmasks
The code in net.cc:get_ifs that sets the netmask omitted sett
The two patches in this series fix the two problems reported in
https://cygwin.com/pipermail/cygwin/2021-July/248970.html
As I indicated in that message, I'm not 100% sure of the second patch.
Ken
Ken Brown (2):
Cygwin: getifaddrs: fix address family for IPv6 netmasks
Cygwin: getifaddrs
The attached patch addresses
https://cygwin.com/pipermail/cygwin/2021-July/248887.html
I don't really understand the GPL issue, but I hope it's OK.
Ken
>From 0321ecd99050ad702a528797af48ea4d01531508 Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Sun, 11 Jul 2021 07:04:58 -0400
Subj
Patch attached.
Sorry for using an attachment, but my smtp server just started using 2-factor
authorization, and I haven't figured out how to make it work with git-send-email.
Ken
>From dfe5988f961ff97d283a9c460e75499db168163a Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Wed, 26 May 2
On 4/27/2021 12:52 PM, Ken Brown wrote:
On 4/27/2021 11:50 AM, Jon Turney wrote:
On 20/04/2021 21:13, Jon Turney wrote:
For ease of reviewing, this patch doesn't contain changes to generated
files which would be made by running ./autogen.sh.
I pushed this patch.
If you have an existing
On 4/27/2021 11:50 AM, Jon Turney wrote:
On 20/04/2021 21:13, Jon Turney wrote:
For ease of reviewing, this patch doesn't contain changes to generated
files which would be made by running ./autogen.sh.
I pushed this patch.
If you have an existing build directory, while you might get away
On 4/27/2021 9:19 AM, Corinna Vinschen wrote:
On Apr 26 15:37, Ken Brown wrote:
Following POSIX and Linux, allow a connected DGRAM socket's connection
to be reset (so that the socket becomes unconnected). This is done by
calling connect and specifing an address whose family is AF_UNSPEC
Following POSIX and Linux, allow a connected DGRAM socket's connection
to be reset (so that the socket becomes unconnected). This is done by
calling connect and specifing an address whose family is AF_UNSPEC.
---
winsup/cygwin/fhandler_socket_inet.cc | 21 --
When connect is called on a DGRAM socket, the call to Winsock's
connect can immediately return successfully rather than failing with
WSAEWOULDBLOCK. Set the connect state to "connected" in this case.
Previously the connect state remained "connect_pending" after the
successful connection.
---
On 3/24/2021 2:55 PM, Hans-Bernhard Bröker wrote:
Am 23.03.2021 um 10:30 schrieb Corinna Vinschen via Cygwin-patches:
> On Mar 22 22:54, Hans-Bernhard Bröker wrote:
>> Am 22.03.2021 um 16:22 schrieb Johannes Schindelin:
>>> One of those under-documented reparse point types is the WSL symbolic
[Still CC Marco]
On 3/22/2021 7:43 AM, Corinna Vinschen via Cygwin-patches wrote:
[CC Marco]
On Mar 22 08:07, Takashi Yano via Cygwin-patches wrote:
On Sun, 21 Mar 2021 17:44:27 +0900
Takashi Yano wrote:
On Sun, 21 Mar 2021 13:01:24 +0900
Takashi Yano wrote:
Takashi Yano (2):
Cygwin:
On 3/8/2021 2:09 PM, Achim Gratz wrote:
Brian Inglis writes:
It's normally a merge conflict which will not be satisfied by regular
commands to restore the working files to upstream.
So you're pulling on an unclean work tree? That's a no-no, either keep
your changes on a separate branch (that
linkat(olddirfd, oldpath, oldname, newdirfd, newname, AT_EMPTY_PATH)
is supposed to create a link to the file referenced by olddirfd if
oldname is the empty string. Currently this is done via the /proc
filesystem by converting the call to
linkat(AT_FDCWD, "/proc/self/fd/", newdirfd, newname,
If linkat(2) is called with AT_EMPTY_PATH on an AF_LOCAL or
AF_UNIX socket that is not a socket file, the current code calls
fhandler_disk_file::link in most cases. The latter expects to be
operating on a disk file and uses the socket's io_handle, which
is not a file handle.
Fix this by calling
If facl(2) is called on an AF_LOCAL or AF_UNIX socket that is not a
socket file, the current code calls fhandler_disk_file::facl in most
cases. The latter expects to be operating on a disk file and uses the
socket's io_handle, which is not a file handle.
Fix this by calling
If fchown(2) is called on an AF_LOCAL or AF_UNIX socket that is not a
socket file, the current code calls fhandler_disk_file::fchown in most
cases. The latter expects to be operating on a disk file and uses the
socket's io_handle, which is not a file handle.
Fix this by calling
If fstat(2) is called on an AF_LOCAL or AF_UNIX socket that is not a
socket file, the current code calls fstat_fs. The latter expects to
be operating on a disk file and uses the socket's io_handle, which is
not a file handle.
Fix this by calling fstat_fs only if the fhandler_socket object is a
If fstatvfs(2) is called on an AF_LOCAL or AF_UNIX socket that is not
a socket file, the current code calls fhandler_disk_file::fstatvfs in
most cases. The latter expects to be operating on a disk file and
uses the socket's io_handle, which is not a file handle.
Fix this by calling
If fchmod(2) is called on an AF_LOCAL or AF_UNIX socket that is not a
socket file, the current code calls fhandler_disk_file::fchmod in most
cases. The latter expects to be operating on a disk file and uses the
socket's io_handle, which is not a file handle.
Fix this by calling
is associated with a socket file. If not, we call an
fhandler_socket_wsock or fhandler_socket method instead of an
fhandler_disk_file method.
The last patch is just a code simplification that arose while I was
working on fhandler_socket_local::link.
Ken Brown (7):
Cygwin: fix fstat on sockets
own here.
Ken Brown (1):
Cygwin: facl: fail with EBADF on files opened with O_PATH
winsup/cygwin/sec_acl.cc | 5 +
1 file changed, 5 insertions(+)
--
2.30.0
This is in the spirit of the Linux requirement that file operations
like fchmod(2), fchown(2), and fgetxattr(2) fail with EBADF on files
opened with O_PATH.
---
winsup/cygwin/sec_acl.cc | 5 +
1 file changed, 5 insertions(+)
diff --git a/winsup/cygwin/sec_acl.cc b/winsup/cygwin/sec_acl.cc
This was done for the fhandler_socket_local class in commits
3a2191653a, 141437d374, and 477121317d, but the fhandler_socket_unix
class was overlooked.
---
winsup/cygwin/fhandler.h | 1 +
winsup/cygwin/fhandler_socket_unix.cc | 24
2 files changed, 25
When a FIFO is opened, syscalls.cc:open always calls fstat on the
newly-created fhandler_fifo. This results from a call to
device_access_denied.
To speed-up this fstat call, and therefore the open(2) call, use
PC_KEEP_HANDLE when the fhandler is created. The resulting
conv_handle is retained
Previously, the call to get_file_attribute for FIFOs set the first
argument to NULL instead of the handle h returned by get_stat_handle,
thereby forcing the file to be opened for fetching the security
descriptor in get_file_sd(). This was done because h might have been
a pipe handle rather than a
The first patch fixes a bug, in which fstat on FIFOs sometimes used
pipe handles instead of file handles.
The second and third patches should improve the efficiency of fstat
and open on FIFOs.
Ken Brown (3):
Cygwin: define fhandler_fifo::fstat
Cygwin: fstat_helper: always use handle in call
Previously fstat on a FIFO would call fhandler_base::fstat.
The latter is not appropriate if fhandler_fifo::open has already been
called (and O_PATH is not set), for the following reason. If a FIFO
has been opened as a writer or duplexer, then it has an io_handle that
is a pipe handle rather
This reverts commit 76dca77f049271e2529c25de8a396e65dbce615d. That
commit was based on the incorrect assumption that get_stat_handle,
when called on a FIFO in fstat_helper, would always return a handle
that is safe to use for getting the file information.
That assumption is true in many cases
--> fhaccess --> fstat,
and this is one of the cases where greater efficiency is possible.
Ken Brown (1):
Revert "Cygwin: fstat_helper: always use handle in call to
get_file_attribute"
winsup/cygwin/fhandler_disk_file.cc | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
--
2.30.0
On 1/30/2021 11:34 AM, Ken Brown via Cygwin-patches wrote:
This patch attempts to fix the problem reported here:
https://cygwin.com/pipermail/cygwin/2020-September/246362.html
See also the followup here:
https://cygwin.com/pipermail/cygwin/2021-January/247666.html
The problem, briefly
Allow check_reparse_point_target to recognize reparse points with
reparse tag IO_REPARSE_TAG_AF_UNIX. These are used in recent versions
of Windows 10 to represent AF_UNIX sockets.
check_reparse_point_target now returns PATH_REP on files of this type,
so that they are treated as known reparse
\n", clen);
printf("strlen = %zd\n", strlen(addr.sun_path));
printf("name = %s\n", addr.sun_path);
}
}
Ken Brown (1):
Cygwin: recognize native Windows AF_UNIX sockets as reparse points
winsup/cygwin/path.cc | 4
1 file changed, 4 insertions(+)
--
2.30.0
The new header defines some Cygwin-specific limits, using private
names. It is included by include/limits.h.
For example, we now have
#define __OPEN_MAX 3200
in include/cygwin/limits.h and
#define OPEN_MAX __OPEN_MAX
in include/limits.h. The purpose is to hide implementation details
Replace all occurrences of OPEN_MAX_MAX by OPEN_MAX, and define the
latter to be 3200, which was the value of the former. In view of the
recent change to getdtablesize, there is no longer a need to
distinguish between these two macros.
---
winsup/cygwin/dtable.cc| 8
Now that getdtablesize always returns OPEN_MAX_MAX, we can simplify
sysconf(_SC_OPEN_MAX) and getrlimit(RLIMIT_NOFILE) to just use that
same constant instead of calling getdtablesize.
---
winsup/cygwin/resource.cc | 5 +
winsup/cygwin/sysconf.cc | 11 +--
2 files changed, 2
a first attempt to implement the suggestion of adding a new
header. At this writing I'm not completely sure
that I fully understand the purpose of that. My choice of which
macros to define in it might need to be changed.
Ken Brown (4):
Cygwin: getdtablesize: always return OPEN_MAX_MAX
Cygwin
According to the Linux man page for getdtablesize(3), the latter is
supposed to return "the maximum number of files a process can have
open, one more than the largest possible value for a file descriptor."
The constant OPEN_MAX_MAX is the only limit enforced by Cygwin, so we
now return that.
On 1/28/2021 5:28 PM, Ken Brown via Cygwin-patches wrote:
On 1/28/2021 11:13 AM, Corinna Vinschen via Cygwin-patches wrote:
On Jan 28 17:07, Corinna Vinschen via Cygwin-patches wrote:
On Jan 28 08:42, Ken Brown via Cygwin-patches wrote:
On 1/28/2021 5:20 AM, Corinna Vinschen via Cygwin
On 1/28/2021 11:13 AM, Corinna Vinschen via Cygwin-patches wrote:
On Jan 28 17:07, Corinna Vinschen via Cygwin-patches wrote:
On Jan 28 08:42, Ken Brown via Cygwin-patches wrote:
On 1/28/2021 5:20 AM, Corinna Vinschen via Cygwin-patches wrote:
On Jan 27 21:51, Ken Brown via Cygwin-patches
On 1/28/2021 11:07 AM, Corinna Vinschen via Cygwin-patches wrote:
On Jan 28 08:42, Ken Brown via Cygwin-patches wrote:
On 1/28/2021 5:20 AM, Corinna Vinschen via Cygwin-patches wrote:
On Jan 27 21:51, Ken Brown via Cygwin-patches wrote:
According to the Linux man page for getdtablesize(3
On 1/28/2021 5:20 AM, Corinna Vinschen via Cygwin-patches wrote:
On Jan 27 21:51, Ken Brown via Cygwin-patches wrote:
According to the Linux man page for getdtablesize(3), the latter is
supposed to return "the maximum number of files a process can have
open, one more than the largest pos
According to the Linux man page for getdtablesize(3), the latter is
supposed to return "the maximum number of files a process can have
open, one more than the largest possible value for a file descriptor."
The constant OPEN_MAX_MAX is the only limit enforced by Cygwin, so we
now return that.
Allow fchmodat with the AT_SYMLINK_NOFOLLOW flag to succeed on
non-symlinks. Previously it always failed, as it does on Linux. But
POSIX permits it to succeed on non-symlinks even if it fails on
symlinks.
The reason for following POSIX rather than Linux is to make gnulib
report that fchmodat
1 - 100 of 473 matches
Mail list logo
