Accomplish this by replacing `GetDiskFreeSpaceW()` with
`NtQueryVolumeInformationFile()` which allows us to represent blocks
larger than 2^32 - 1 via
`FILE_FS_FULL_SIZE_INFORMATION.TotalAllocationUnits`.
Expanded `fs_statfs` test to check that `uv_fs_statfs()` also works with
files, meaning https://github.com/libuv/libuv/issues/2683 remains fixed
without the need of https://github.com/libuv/libuv/pull/2695.
The test is multi-threaded and expects both threads to receive at least
some of the incoming connections but there isn't always true parallelism
under QEMU's user-mode emulator.
Single-core systems are also susceptible to that so also add a check
that we have at least two cores to run on.
As mentioned in the change for the udp_reuseport test from a few days
ago, the test is not perfect (there being > 1 core doesn't guarantee
we actually get to run on them) but it's better than nothing.
Fixes: https://github.com/libuv/libuv/issues/5003
The test is multi-threaded and expects both threads to receive at least
some of the incoming datagrams but there isn't always true parallelism
under QEMU's user-mode emulator.
Single-core systems are also susceptible to that so also add a check
that we have at least two cores to run on.
It's not perfect because a sufficiently dedicated test torturer could
probably concoct a containerized setup where the core count > 1 but the
available CPU slice is so small that the test effectively still runs
sequentially, but it's better than nothing.
Fixes: https://github.com/libuv/libuv/issues/4777
It was reported that PTYs on Linux sometimes report POLLHUP, return a
partial read, but still return more data on the next read.
Libuv contains an optimization where it assumes a partial read after
POLLHUP means the next read can be skipped because it's going to fail
with EOF anyway. That assumption was thought to be always true but,
alas, it isn't.
The fact the optimization has been present for 13 years and this is the
first bug report about it, indicates how rare this particular condition
is, but of course we can't skim on correctness.
The reworked optimization only uses POLLHUP as an input signal when
POLLIN is not also set. That means we no longer have to track partial
reads because we're going to try and read anyway as long as POLLIN is
set. It seems to cause no measurable regressions on the test suite or
the (lightly tested) benchmarks.
Fixes: https://github.com/libuv/libuv/issues/4992
Check the length before doing the compare like we do a few lines below,
not the other way around. It's a false positive because the length is
capped well below the maximum object size but it's an easy fix.
Fixes the following warning:
test/test-poll-oob.c:94:19: warning: ‘strncmp’ specified bound
[18446744071562067968, 18446744073709551615] exceeds maximum
object size 9223372036854775807 [-Wstringop-overread]
If uv_spawn() fails after uv__handle_init() has been called, the handle
remains in loop->handle_queue. This causes use-after-free if the handle
is stack-allocated or freed, and a subsequent loop operation like
uv_walk() accesses it.
This follows the same pattern as uv_tcp_init_ex() which explicitly
removes the handle from the queue on error.
The initial FindFirstFile can fail with ERROR_FILE_NOT_FOUND, meaning
no matches (read: empty directory), which leaves dir_handle set to
INVALID_HANDLE_VALUE. Not an actual error, it just means no results.
I can't get FindFirstFile to work like that on regular file systems
but it's been reported that it does under sshfs-win and the MSDN
documentation clearly states it's possible. Handle it.
Fixes: https://github.com/libuv/libuv/issues/4952
Remove the microsecond truncation in uv__fs_to_timespec() function to enable
full nanosecond resolution support. The utimensat() system call already
supports nanosecond precision, so the artificial truncation to microseconds
is no longer necessary.
This allows file modification and access times to be set with full nanosecond
precision instead of being limited to microsecond resolution.
Fixes the TODO comment about removing the microsecond resolution limit.
Fetch file metadata by handle instead of by path, otherwise there is a
race window between fetching and acting on said metadata where another
process can replace the file with another one.
There is still a potential race when upgrading the short path to a long
path but that that one is intrinsic. It's not something libuv can solve
except by refraining from calling GetLongPathName.
Fixes: https://github.com/libuv/libuv/issues/4568
The `flags` argument to `uv__udp_recvmsg_errqueue` was not initialized
in all code paths. Shuffle code around to make the control flow more
obvious (at the cost of a less legible diff.)
Also fixes an unused label warning when building on systems that aren't
Linux.
Introduced last month in commit 80a5e3ba0, "linux: add MSG_ERRQUEUE
ipv4/ipv6 udp support".
Add a stub function for no-ahafs builds. src/unix/core.c won't actually
call uv__ahafs_event but the linker still needs to see a symbol.
Like commit 87943b03 but for IBM i instead of AIX this time.
The test previously assumed a default nice value of 0, but this can vary
depending on PAM configuration, /etc/security/limits.conf, or other environment
settings.
Fixes: https://github.com/libuv/libuv/issues/4898
Signed-off-by: Juan José Arboleda <soyjuanarbol@gmail.com>
While unlikely that this fails (since it is implemented to call
`abort()` instead of actually return an error code, we would
theoretically leak this state. The process state init doesn't actually
have a cleanup, and just awkwardly relies on uv_signal_close being
unnecessary (which is likely true though).
There is a minor error about the return value of uv_cancel
for tasks that are already executing. All other parts of the
documentation correctly states that uv_cancel will fail.
_snwprintf_s takes its length argument in characters, not bytes.
Does not appear to be a security issue because the paths are not under
an attacker's control unless the system has been compromised beyond
salvation: requires a combination of being able to set the name of the
executable and/or changing %LOCALAPPDATA% or a registry key.
Refs: https://github.com/libuv/libuv/security/advisories/GHSA-jjrx-vr7q-7732
