On 7/20/2020 10:43 AM, Ken Brown via Cygwin-patches wrote:
On 7/20/2020 10:23 AM, Corinna Vinschen wrote:
On Jul 20 09:34, Ken Brown via Cygwin-patches wrote:
Commit 605bdcd410384dda6db66b9b8cd19e863702e1bb enabled mapping beyond
EOF in 64 bit environments. But the variable 'orig_len' did
On 7/20/2020 11:41 AM, Corinna Vinschen wrote:
On Jul 20 10:58, Ken Brown via Cygwin-patches wrote:
On 7/20/2020 10:49 AM, Ken Brown via Cygwin-patches wrote:
On 7/20/2020 10:43 AM, Ken Brown via Cygwin-patches wrote:
On 7/20/2020 10:23 AM, Corinna Vinschen wrote:
On Jul 20 09:34, Ken Brown
On 7/20/2020 10:49 AM, Ken Brown via Cygwin-patches wrote:
On 7/20/2020 10:43 AM, Ken Brown via Cygwin-patches wrote:
On 7/20/2020 10:23 AM, Corinna Vinschen wrote:
On Jul 20 09:34, Ken Brown via Cygwin-patches wrote:
Commit 605bdcd410384dda6db66b9b8cd19e863702e1bb enabled mapping beyond
EOF
On 11/5/2020 2:47 PM, Jon Turney wrote:
+# temporary directory to be used for files created by tests (as an absolute,
+# /cygdrive path, so it can be understood by the test DLL, which will have
+# different mount table)
+tmpdir = $(shell cygpath -ma $(objdir)/testsuite/tmp/ | sed -e
On 11/8/2020 1:52 PM, Jon Turney wrote:
On 08/11/2020 18:19, Ken Brown via Cygwin-patches wrote:
On 11/5/2020 2:47 PM, Jon Turney wrote:
+# temporary directory to be used for files created by tests (as an absolute,
+# /cygdrive path, so it can be understood by the test DLL, which will have
Replace the 'WCHAR pipe_name_buf[48]' class member by 'PWCHAR
pipe_name_buf', and allocate space for the latter as needed.
Change the default constructor to accommodate this change, and add a
destructor that frees the allocated space.
Also change get_pipe_name and clone to accommodate this
Don't call cstrdup on NULL pointers.
---
winsup/cygwin/path.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/winsup/cygwin/path.h b/winsup/cygwin/path.h
index b94f13df8..0b3e72fc1 100644
--- a/winsup/cygwin/path.h
+++ b/winsup/cygwin/path.h
@@ -320,9 +320,11 @@ class
On 11/16/2020 7:08 AM, Corinna Vinschen wrote:
On Nov 14 09:16, Ken Brown via Cygwin-patches wrote:
Don't call cstrdup on NULL pointers.
---
winsup/cygwin/path.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/winsup/cygwin/path.h b/winsup/cygwin/path.h
index
Traverse the fifo_client_handler list from the top down to try to
avoid copying.
---
winsup/cygwin/fhandler_fifo.cc | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/winsup/cygwin/fhandler_fifo.cc b/winsup/cygwin/fhandler_fifo.cc
index eff05d242..8b67037cb 100644
On 11/9/2020 11:25 AM, Jon Turney wrote:
On 08/11/2020 19:27, Ken Brown via Cygwin-patches wrote:
On 11/8/2020 1:52 PM, Jon Turney wrote:
On 08/11/2020 18:19, Ken Brown via Cygwin-patches wrote:
On 11/5/2020 2:47 PM, Jon Turney wrote:
+# temporary directory to be used for files created
On 10/12/2020 2:02 PM, Ken Brown via Cygwin-patches wrote:
It looks to me like there's been a bug in the MSG_WAITALL support for
AF_INET and AF_LOCAL sockets ever since that support was first
introduced 13 years ago in commit 023a2fa7. If I'm right, MSG_WAITALL
has never worked.
This patch
When .. is in the source path and the path prefix exists but is not a
directory, return ENOTDIR instead of ENOENT. This fixes a failing
gnulib test of realpath(3).
Addresses: https://lists.gnu.org/archive/html/bug-gnulib/2021-01/msg00214.html
---
winsup/cygwin/path.cc | 4 +++-
On 1/25/2021 1:57 PM, Corinna Vinschen via Cygwin-patches wrote:
On Jan 25 12:24, Ken Brown via Cygwin-patches wrote:
Following POSIX, ensure that ctime is updated if chown succeeds,
unless the new owner is specified as (uid_t)-1 and the new group is
specified as (gid_t)-1. Previously, ctime
Following POSIX, ensure that ctime is updated if chown succeeds,
unless the new owner is specified as (uid_t)-1 and the new group is
specified as (gid_t)-1. Previously, ctime was unchanged whenever the
owner and group were both unchanged.
Aside from POSIX compliance, this fix makes gnulib report
On 1/20/2021 1:00 PM, Ken Brown via Cygwin-patches wrote:
Following Linux, return ENOTTY on a bad file descriptor and also set
errno to ENOTTY.
Previously 0 was returned and errno was set to EBADF. Returning 0
violates the requirement in
https://man7.org/linux/man-pages/man3/ptsname_r.3.html
This documents commit b951adce, "Cygwin: add flag to indicate reparse
points unknown to WinAPI".
---
winsup/cygwin/release/3.2.0 | 3 +++
1 file changed, 3 insertions(+)
diff --git a/winsup/cygwin/release/3.2.0 b/winsup/cygwin/release/3.2.0
index 132d5c810..c18a848de 100644
---
On 1/15/2021 12:42 PM, Ken Brown via Cygwin-patches wrote:
This documents commit b951adce, "Cygwin: add flag to indicate reparse
points unknown to WinAPI".
Sorry, there's a mistake in the commit message. A corrected version is on the
way.
Ken
This documents commit aec64798, "Cygwin: add flag to indicate reparse
points unknown to WinAPI".
---
winsup/cygwin/release/3.2.0 | 3 +++
1 file changed, 3 insertions(+)
diff --git a/winsup/cygwin/release/3.2.0 b/winsup/cygwin/release/3.2.0
index 132d5c810..c18a848de 100644
---
On 1/13/2021 3:56 AM, Corinna Vinschen via Cygwin-patches wrote:
Hi Ken,
Happy New Year, btw :)
Thanks, same to you!
Ken
This fixes a bug on 32-bit Cygwin that was introduced in commit
84252946, "Cygwin: fstatat, fchownat: support the AT_EMPTY_PATH flag".
Add a comment explaining why fstat should not be called.
Addresses: https://cygwin.com/pipermail/cygwin/2021-January/247399.html
---
winsup/cygwin/release/3.2.0
On 1/26/2021 4:30 PM, Ken Brown via Cygwin-patches wrote:
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
On 1/27/2021 7:40 AM, Corinna Vinschen via Cygwin-patches wrote:
On Jan 26 16:30, Ken Brown via Cygwin-patches wrote:
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
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
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
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.
This patchset is an extension of the patch submitted here:
https://cygwin.com/pipermail/cygwin-patches/2021q1/011060.html
That patch is included as the first patch in this set. The change to
OPEN_MAX still needs testing to see if it has too much impact on the
performance of tcsh.
I've make a
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
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
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 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
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
On 1/27/2021 8:27 AM, Corinna Vinschen via Cygwin-patches wrote:
On Jan 27 08:22, Ken Brown via Cygwin-patches wrote:
On 1/27/2021 7:40 AM, Corinna Vinschen via Cygwin-patches wrote:
On Jan 26 16:30, Ken Brown via Cygwin-patches wrote:
Allow fchmodat with the AT_SYMLINK_NOFOLLOW flag
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
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
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, is that on certain recent versions of Windows
10, including
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
Commit 76dca77f04 had a careless blunder, so this patch reverts it.
Nevertheless, fstat(2) can be made more efficient on FIFOs, and I'm
working on a separate patchset to do this right. It's worth doing,
because every call to open(2) on a FIFO leads to a call chain
device_access_denied -->
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
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
[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:
Several of the fhandler_socket_local and fhandler_socket_unix methods
that support system calls are written as though they are operating on
socket files unless the socket is an abstract socket. This patchset
(except for the last patch) attempts to fix this by checking whether
the fhandler is
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
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 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 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 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
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,
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
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
I'm not sure if this patch is right. Should facl fail on all commands
or just on SETACL? If the command is GETACL, for example, should this
fail like fgetxattr(2) or should it succeed like fstat(2)?
Cygwin may be the only platform that supports both facl(2) and O_PATH,
so I guess we're on our
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
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, 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
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 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
101 - 157 of 157 matches
Mail list logo
