- If an UNC path is mounted to a drive using SMB3.11, accessing to
the drive fails with error "Too many levels of symbolic links."
This patch fixes the issue.
A single Makefile rule creates three files in three steps, the second
and third one never showing up in dependencies. The next step creating
the link lib only depends on the first of these files. Even if the
second or third step in the DLL build rule fails, the next make
invocation never picks up on this and just goes ahead creating the
link lib.
Fix this by splitting the DLL build rule into three rules, with
every step on the way depending on the previous rule. Also fix up
the names, TEST_DLL_NAME just doesn't cut it.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This reverts commit 0390cc8572.
There's no indication what exact situation this patch was supposed to
solve, and local testing doesn't show any such problems. However, this
patch itself introduced a new problem, as outlined by
https://cygwin.com/pipermail/cygwin/2022-January/250629.html
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Commit a2bfe7cae6 introduced a change ignoring default ACEs on files
to come up with a valid POSIX ACL, reflecting the Windows ACEs actually
making sense on files.
However, if CREATOR OWNER or CREATOR GROUP ACEs - both only making sense
as default ACEs - are found in the ACL, a value indicating the presence
of default ACEs gets set, even on files. This in turn breaks a
subsequent integrity check and get_posix_access returns EINVAL.
The code path handling default ACEs on directories sets this indicator
anyway, so don't set it just because one of the above SIDs are found.
Fixes: a2bfe7cae6 ("Cygwin: ACLs: ignore *_INHERIT flags in file ACLs")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
In case when the native OS resolver is used (via os_query) the returned
response ID is always 0. It should actually match the ID passed in to
res_send() in the DNS request header. This patch fixes that
- Make sure the answer buffer is properly cleared so there is no trailing
garbage when the response does not fit entirely in;
- Make sure an internal decomp failure gets reported correctly (w/return code -1);
- Make sure that the buffer is not overrun when filling out the header.
When trying to create a directory called `xyz` in the presence of a
directory `xyz.lnk`, the Cygwin runtime errors out with an `ENOENT`.
The root cause is actually a bit deeper: the `symlink_info::check()`
method tries to figure out whether the given path refers to a symbolic
link as emulated via `.lnk` files, but since it is a directory, that is
not the case, and that hypothesis is rejected.
However, the `fileattr` field is not cleared, so that a later
`.exists()` call on the instance mistakenly thinks that the symlink
actually exists. Let's clear that field.
This fixes https://github.com/msys2/msys2-runtime/issues/81
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
AAAA records returned from Windows resolver were flagged as "No
structure" in debug output because of being processed (although
correctly) in the default catch-all case. This patch makes the AAAA
records properly recognized.
- If the from_master is closed before cleaning up other pipes, such
as from_slave_nat, the same pty may be allocated and pty master may
try to open the pipe which is not closed yet, and it will fail.
This patch fixes the issue.
- Closing attach_mutex and recreating it causes the race issue
between pty and console codes. With this patch, attach_mutex
is created only once in a process which opens pty, and never
closed in order to avoid this issue.
Addresses:
https://cygwin.com/pipermail/cygwin-developers/2021-December/012548.html
- If master_fwd_thread is terminated by cygthread::terminate_thread(),
the opportunity to release tmp_pathbuf is missed, resulting in a
memory leak. This patch fixes the issue.
- GDB inferior may be suspended while the inferior grabs mutex.
This causes deadlock in terminal I/O. With this patch, timeout
for waiting mutex is set to 0 for the debugger process when the
process calls CreateProcess() with DEBUG_PROCESS flag to avoid
deadlock. This may cause the race issue in GDB, however, there
is no other way than that.
Addresses:
https://cygwin.com/pipermail/cygwin-developers/2021-December/012542.html
32 bit Cygwin still exports function calls to support old applications.
E. g., when switching from 16 to 32 bit uid/gid values, new function
like getuid32 have been added and the old getuid function still only
provides 16 bit values. Newly built applications using getuid are
actually calling getuid32.
However, this link magic isn't performed inside Cygwin itself, so if
newlib functions call getuid, they actually call the old getuid, not
the new getuid32. This leads to truncated uid/gid values.
https://cygwin.com/pipermail/cygwin/2022-January/250453.html reports
how this leads to problems in posix_spawn.
Fix this temporarily. i686 support will go away soon in Cygwin and the
fix can be dropped.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
We need deps to newlib's libc.a and libm.a, otherwise changes
in newlib code don't trigger a rebuild of the Cygwin DLL.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
get_posix_access() creates DEF_*_OBJ aclent_t entries from Windows ACEs
with INHERIT flags set, independent of the file type. These flags only
make sense on directory objects, but certain Windows functions don't
check the file type and allow INHERIT ACE flags even on non-directories.
As a fix, make sure to ignore the INHERIT flags on non-directory ACLs
and don't propagate the matching DEF_*_OBJ aclent_t entries to callers.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
NtQueryInformationProcess(ProcessHandleInformation) can return
STATUS_SUCCESS with invalid handle data for certain processes
("minimal" processes on Windows 10). This can cause a crash when
there's an attempt to access that data. Fix that by setting
NumberOfHandles to zero before calling NtQueryInformationProcess.
Addresses: https://cygwin.com/pipermail/cygwin-patches/2021q4/011611.html
- This patch fixes the failure of input switching between io_handle
and io_handle_nat. This very rarely happens, however, input is
wrongly switched to io_handle_nat even though the non-cygwin app
is in the background.
- The recent commit "Cygwin: pty: Add missing input transfer when
switch_to_pcon_in state." causes regression that rlwrap cannot
work with cmd.exe. This patch fixes the issue.
- The recent commit: "Cygwin: pty: Fix Ctrl-C handling for non-cygwin
apps in background." causes the problem that cmd.exe is terminated
by Ctrl-C even if it is running in pseudo console. This patch fixes
the issue.
- With this patch, FILE_SYNCHRONOUS_IO_NONALERT flag is applied to
the read pipe so that native C# programs work with cygwin pipe.
To handle signals in reading pipe with this flag set, the read
pipe itself is always set to nonblocking mode and simulates the
blocking behaviour in raw_read().
- Default to byte mode rather than message mode in order to make
C# programs work with cygwin pipe.
Addresses: https://cygwin.com/pipermail/cygwin/2021-March/247987.html
- With pseudo console enabled, if the non-cygwin app is started in
the background and put it into the foreground, the process cannot
be stopped by Ctrl-C. This patch fixes the issue.
- This patch fixes the bug that input is wrongly sent to io_handle_nat
rather than io_handle when neither read() nor select() is called
after the cygwin app is started from non-cygwin app. This happens
only if psuedo console is disabled.
Addresses:
https://cygwin.com/pipermail/cygwin-patches/2021q4/011587.html
- The last change in path.cc introduced a bug that causes an error
when accessing a virtual drive which mounts UNC path such as
"\\server\share\dir" rather than "\\server\share". This patch
fixes the issue.
Rather than special case status code 0xc00004b3, add status and matching
error code to ntdll.h and handle it as part of the standard error mapping.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
To keep getrlimit/setrlimit clean, move the RLIMIT_AS code into
local static functions __set_rlimit_as and __get_rlimit_as.
Also, make adding process to the job the last step, to be able to
close and release the job resources if anything failed. Add matching
comment.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
If the incoming soft limit is less restrictive than the current
hard limit, bail out with EPERM. Given the previous sanity check,
this implies trying to raise the hard limit. While, theoretically,
this should be allowed for privileged processes, Windows has no
matching concept in terms of job limits
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Code based on the idea implemented by the oneTBB project,
see https://github.com/oneapi-src/oneTBB
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
NtReadFile can return STATUS_PENDING occasionally even in non-blocking
mode. Check for this and wait for NtReadFile to complete. To avoid
code repetition, do this in a static helper function nt_read.
https://cygwin.com/pipermail/cygwin/2021-November/249930.html
reported a regression introduce by using a dynamically sized local
char array in favor of a statically sized array.
Fix this by reverting to a statically sized array, using a small
buffer on the stack for a reasonable number of requested digits, a
big mallocated buffer otherwise. This should work for small targets
as well, given that malloc is used in printf anyway right now.
This is *still* hopefully just a temporary measure, unless somebody
actually provides a new ldtoa.
Fixes: 4d90e53359 ("ldtoa: fix dropping too many digits from output")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
raise(2) on Linux returns the same values and sets errno
independent of calling kill(2) or pthread_kill(3). Align
code to behave the same.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The check for the pthread self pointer in TLS is misleading,
given the main thread has this pointer initialized as well.
Check for the global __isthreaded flag as well.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
- This patch fixes the issue that process sometimes hangs for 60
seconds with the following scenario.
1) Open command prompt.
2) Run "c:\cygwin64\bin\bash -l"
3) Compipe the following source with mingw compiler.
/*--- Begin ---*/
#include <stdio.h>
int main() {return getchar();}
/*---- End ----*/
4) Run "tcsh -c ./a.exe"
5) Hit Ctrl-C.
The file attributes after creating a file are not necessarily
identical to the attributes we passed as argument to NtCreateFile.
This results in subsequent operations like fchmod or facl to
set the DOS file attributes to unexpected values.
The fix is to request file attributes from the OS after file creation
and cache those.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
When running Cygwin's Bash in the Windows Terminal (see
https://docs.microsoft.com/en-us/windows/terminal/ for details), Cygwin
is receiving keyboard input in the form of UTF-16 characters.
UTF-16 has that awkward challenge that it cannot map the full Unicode
range, and to make up for it, there are the ranges U+D800-U+DBFF and
U+DC00-U+DFFF which are illegal except when they come in a pair encoding
for Unicode characters beyond U+FFFF.
Cygwin does not handle such surrogate pairs correctly at the moment, as
can be seen e.g. when running Cygwin's Bash in the Windows Terminal and
then inserting an emoji (e.g. via Windows + <dot>, which opens an emoji
picker on recent Windows versions): Instead of showing an emoji, this
shows the infamous question mark in a black triangle, i.e. the invalid
Unicode character.
Let's special-case surrogate pairs in this scenario.
This fixes https://github.com/git-for-windows/git/issues/3281
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Use the same name as glibc & gnulib to indicate "newlib itself is
being compiled". This also harmonizes the codebase a bit in that
_LIBC was already used in places instead of _COMPILING_NEWLIB.
Building for bfin-elf, mips-elf, and x86_64-pc-cygwin produces
the same object code.
A recent change in binutils marks the .gnu_debuglink_overlay section
as debug section. When dllfixdbg calls objcopy -g, the section
is removed and the --add-gnu-debuglink option on the same command line
appends the section consequentially at the end of the sections.
This in turn breaks Windows Version info and, potentially, raising
the cygheap size at runtime.
Fix this by adding an explicit --keep-section=.gnu_debuglink_overlay
to the objcopy command line.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
isabspath handles a path "X:", without trailing slash or backslash,
as absolute path. This breaks some scenarios with relative paths
starting with "X:". For instance, fstatat will mishandle a call
with valid dirfd and "c:" as path.
The reason is that gen_full_path_at() will check for isabspath("C:")
which returns true. So the path will be used verbatim in fstatat,
rather than being converted to a path "<dirfd-path>/c:".
So, introduce isabspath_strict, which returns true for paths starting
with "X:" only if the next char is actually a slash or backslash.
Use it from gen_full_path_at().
This still fixes only half the problem. The right thing would have been
to disallow using DOS paths in the first place. Unfortunately it's much
too late for that.
Addresses: https://cygwin.com/pipermail/cygwin/2021-November/249837.html
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Cygwin always requests FILE_WRITE_ATTRIBUTES permissions when trying to
change DAC information. This can lead to permission problems when
trying to chmod/chown files on Samba shares. Drop requesting
FILE_WRITE_ATTRIBUTES on Samba shares and go with WRITE_DAC/WRITE_OWNER
only.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Also rename release 3.4.0 to 3.3.2. It doesn't make sense to
duplicate the issues fixed in 3.3.x into the 3.4.0 relnotes.
Only patches not backported into 3.3.x belong into 3.4.0.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
- Currently, bash occasionally exits by Ctrl-C with the following
scenario.
1) Start bash in the command prompt.
2) Run 'exec bash'.
3) Press Ctrl-C several times.
This patch fixes the issue.
- Currently, read() returns EINTR due to a bug if signal handler
is SIG_DFL and the process is suspended by Ctrl-Z and restarted.
This patch fixes the issue.
i. e. Vista/2008. This drops support for the sr_CS locale.
Regenerate LC_MESSAGES and LC_TIME ERA data from more recent Linux
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
i. e., Vista/2008.
AllocConsole appears to allow creating a console only on the currently
visible desktop since Windows 7, which broke the simple code opening
the console on an invisible desktop in an invisible window station.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Per https://cygwin.com/pipermail/cygwin-developers/2021-October/012429.html,
we may encounter a crash when starting multiple threads during process
startup (here: fhandler_fifo::fixup_after_{fork,exec}) which in turn
allocate memory via malloc.
The problem is concurrent usage of malloc before the malloc muto has
been initialized.
To fix this issue, convert the muto to a SRWLOCK and make sure it is
statically initalized. Thus, malloc can be called as early as necessary
and malloc_init is only required to check for user space provided malloc.
Note that this requires to implement a __malloc_trylock macro to be
called from fork.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This patch unifies the layout of the clipboard descriptor cygcb_t for
32- and 64-bit Cygwin. It allows correct copy/paste between the two
environments without corruption of user's copied data and without access
violations due to interpreting that data as a size field.
The definitions of CYGWIN_NATIVE and cygcb_t are moved to a new include
file, sys/clipboard.h. The include file is used by fhandler_clipboard.cc
as well as getclip.c and putclip.c in the Cygwin cygutils package.
When copy/pasting between 32- and 64-bit Cygwin environments, both must
be running version 3.3.0 or later for successful operation.
- The commit b531d6b0 introduced temporary_query_hdl() which uses
SystemHandleInformation. With this patch, ProcessHandleInformation
rather than SystemHandleInformation is used if it is available.
This request is faster, however, is only available since Windows 8,
therefore, SystemHandleInformation is used for Windows Vista and 7
as before.
- The commit f79a4611 introduced query_hdl, which is the read pipe
handle kept in the write pipe instance in order to determine if
the pipe is ready to write in select(). This implementation has
a potential risk that the write side fails to detect the closure
of the read side if more than one writer exists and one of them
is a non-cygwin process.
With this patch, the strategy of commit f79a4611 is used only if
the process is running as a service. For a normal process,
instead of keeping query_hdl in the write pipe instance, it is
retrieved temporarily when select() is called. Actually, we
want to use tenporary query_hdl for all processes, however, it
does not work for service processes due to OpenProcess()
failure.
open_setup is called by dtable::init_std_file_from_handle and
fhandler_base::open_with_arch. In both cases, failure of open_setup
is now a fatal error.
Currently this can only happen in the following situation: A Cygwin
process is started by a non-Cygwin process, one of the standard IO
handles is a pipe handle, and Cygwin is unable to create a required
mutex (read_mtx or hdl_cnt_mtx).
- query_hdl and hdl_cnt_mtx are moved from fhandler_pipe_fifo to
fhandler_pipe. Then reader_closed() is changed to virtual and
overridden in fhandler_pipe.
- This patch fixes the race issue in the handle counting to detect
closure of read pipe, which is introduced by commit f79a4611.
A mutex hdl_cnt_mtx is introduced for this issue.
- Currently, the stderr handle is duplicated in close_all_files().
This interferes the handle counting for detecting closure of read
pipe, which is introduced by commit f79a4611. This patch stops
duplicating stderr handle if it is write pipe.
NtQueryInformationFile hangs if it's called on the read side handle of
a pipe while another thread or process is performing a blocking read.
Avoid select potentially hanging by calling NtQueryInformationFile
only on the write side of the pipe and using PeekNamedPipe otherwise.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
- In pipe_data_available() in select.cc, PeekNamedPipe() call is
not needed if WriteQuotaAvailable is non-zero because we already
know the write pipe has a space. Therefore, with this patch,
PeekNamedPipe() is called only when WriteQuotaAvailable is zero.
This makes select() on pipe faster a bit.
- Currently, raw_read(), raw_write() and close() release select_sem
unconditionally even if no waiter for select_sem exists. With this
patch, only the minimum number of semaphores required is released.
- Usually WriteQuotaAvailable retrieved by NtQueryInformationFile()
on the write side reflects the space available in the inbound buffer
on the read side. However, if a pipe read is currently pending,
WriteQuotaAvailable on the write side is decremented by the number
of bytes the read side is requesting. So it's possible (even likely)
that WriteQuotaAvailable is 0, even if the inbound buffer on the
read side is not full. This can lead to a deadlock situation:
The reader is waiting for data, but select on the writer side
assumes that no space is available in the read side inbound buffer.
Currently, to avoid this stuation, read() does not request larger
block than pipe size - 1. However, this mechanism does not take
effect if the reader side is non-cygwin app.
The only reliable information is available on the read side, so
fetch info from the read side via the pipe-specific query handle
(query_hdl) introduced.
If the query_hdl (read handle) is kept in write side, writer can
not detect closure of read pipe. Therefore, raw_write() counts
write handle and query_hdl. If they are equal, only the pairs of
write handle and query_hdl are alive. In this case, raw_write()
returns EPIPE and raises SIGPIPE.
- Nonblocking pipes (PIPE_NOWAIT) are not well handled by non-Cygwin
tools, so convert pipe handles to PIPE_WAIT handles when spawning
a non-Cygwin process.
We already fetched the correct SECURITY_ATTRIBUTES at the start of
fhandler_pipe::create, so using another SECURITY_ATTRIBUTES object for
the mutex and semaphore objects doesn't make much sense.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
select_sem gets created on the read side with inheritence settings
depending on the O_CLOEXEC flag. Then it gets duplicated to the write
side with unconditional inheritence. Fix that.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Fold all code branches potentially having read or written data into
a single if branch, so signalling select_sem catches all cases.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Rename fhandler_pipe_and_fifo::max_atomic_write to pipe_buf_size.
This reflect its actual meaning better. The fhandler_pipe_and_fifo
constructor initializes it to DEFAULT_PIPEBUFSIZE (== 64K), which is
the buffer size for the windows pipes created by fhandler_pipe and
fhandler_fifo. But if we inherit a stdio pipe handle from a
non-Cygwin process, the buffer size could be different.
To remedy this, add a method fhandler_pipe::set_pipe_buf_size that
queries the OS for the pipe buffer size, and use it in
dtable::init_std_file_from_handle.
Given we return 1 already if WriteQuotaAvailable is > 0, the condition
for tiny pipes is never true. Fix the comments.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
In blocking mode, the underlying IO must always be terminated,
one way or the other, to make sure the application knows the exact
state after returning from the IO function. Therefore, always call
CancelIo in blocking mode.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Just cancelling a thread doesn't cancel async IO started by this thread.
Fix this by returning from cygwait and calling CancelIo before canceling
self.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
- By guarding read with read_mtx, no more than one ReadFile can
be called simultaneously. So couting read handles is no longer
necessary.
- Make raw_read code as similar as possible to raw_write code.
This is a parent of fhandler_pipe and fhandler_fifo for code that is
common between the two classes. Currently it just contains
max_atomic_write and raw_write(). The latter is identical to what
used to be fhandler_pipe::raw_write().
FILE_PIPE_LOCAL_INFORMATION::WriteQuotaAvailable is unreliable.
Usually WriteQuotaAvailable on the write side reflects the space
available in the inbound buffer on the read side. However, if a
pipe read is currently pending, WriteQuotaAvailable on the write side
is decremented by the number of bytes the read side is requesting.
So it's possible (even likely) that WriteQuotaAvailable is 0, even
if the inbound buffer on the read side is not full. This can lead to
a deadlock situation: The reader is waiting for data, but select
on the writer side assumes that no space is available in the read
side inbound buffer.
This patch implements a workaround by never trying to read more than
half the buffer size blocking if the read buffer is empty. This first
cut tries to take the number of open readers into account by reducing
the amount of requested bytes accordingly.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
POSIX requires atomicity for non-blocking writes <= PIPE_BUF bytes
and writing of at least 1 byte if any buffer space is left.
Windows NtWriteFile returns STATUS_SUCCESS and "0 bytes written"
if the write doesn't match buffer space. Fix this discrepancy.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Takashi Yano
Corinna Vinschen
Jon Turney
Anton Lavrentiev via Cygwin-patches
Johannes Schindelin
Brian Inglis
Ken Brown
Mike Frysinger
Mark Geisert