When we send VK_RETURN to make ReadConsole return, a spurious new line
is echoed to the screen. This is pretty visible in Node.js, since it
calls uv_tty_read_start() and uv_tty_read_stop() in rapid succession
during startup.
With this change, we save the screen state just before sending
VK_RETURN, and restore the cursor position as soon as ReadConsole
returns.
PR-URL: https://github.com/libuv/libuv/pull/866
Reviewed-by: Bert Belder <bertbelder@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Since we cancel ReadConsole by sending a newline, the duplicate
handle is no longer necessary.
PR-URL: https://github.com/libuv/libuv/pull/866
Reviewed-by: Bert Belder <bertbelder@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Closing the handle does not make ReadConsoleW exit reliably on
Windows 7 and above. Thus, after switching from line to raw mode,
keypresses were held until enter was pressed. This makes ReadConsoleW
exit by writing a return keypress to its input buffer, similar to
what was already done for raw mode.
Fixes: https://github.com/libuv/libuv/issues/852
PR-URL: https://github.com/libuv/libuv/pull/866
Reviewed-by: Bert Belder <bertbelder@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
This commit adds a previously missing call to
uv__fs_scandir_cleanup() to uv_fs_req_cleanup(). This better
aligns the Windows and Unix implementations.
Fixes: https://github.com/libuv/libuv/issues/873
PR-URL: https://github.com/libuv/libuv/pull/874
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
- take a size parameter
- always null terminate the buffer
- nullify the output parameter in case of error
PR-URL: https://github.com/libuv/libuv/pull/859
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
The code for handling fs events is quite complex, this commits tries to
make it easier to follow.
First, there are 2 cases in which we use the name of the file straight
from the event (when watching a directory):
- if we cannot create the long path
- if the file got renamed or removed
So separate this logically, even if the code we need is the same.
Second, one way or anothwer we will always have some filename to report,
so remove an unnecessary if.
Third, nullify filenamew, to avoid having a dangling pointer, should the
code change.
PR-URL: https://github.com/libuv/libuv/pull/858
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
This commit populates the ru_majflt and ru_maxrss fields of
uv_getrusage() on Windows.
PR-URL: https://github.com/libuv/libuv/pull/805
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
It has been reported that for SharePoint connections mapped as a drive,
uv_fs_scandir() returns "." and ".." entries when the expectation is
that they should be filtered out.
After some investigation it looks like the driver returns ".\0" and
"..\0" for those entries, that is, it includes the zero byte in the
filename length. Rewrite the filter to catch those entries as well.
Fixes: https://github.com/nodejs/node/issues/4002
PR-URL: https://github.com/libuv/libuv/pull/636
Reviewed-By: Alexis Campailla <orangemocha@nodejs.org>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
wcslen() returns a size_t, not an int.
Add bounds checking to dirlen to avoid undefined if dirlen is 0.
Cache relpath size calculation to replace redundant (- 1 + 1)
expression while still showing workings.
Change uv_relative_path return type to void and remove dead code which
branched on the return value.
PR-URL: https://github.com/libuv/libuv/pull/699
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
When converting an absolute path to a relative path on Windows,
uv_relative_path assumed that the relative path could be no longer than
MAX_PATH characters, and would allocate a buffer of MAX_PATH characters
for the relative path.
However, where a recursive watch is started for a directory using a UNC
path, and where events within that directory occur for pathnames longer
than MAX_PATH, it is possible for the relative path to exceed MAX_PATH
characters and overflow the buffer.
This commit fixes uv_relative_path to allocate a buffer for the exact
number of characters counted in the relative path.
Fixes: https://github.com/libuv/libuv/issues/693
PR-URL: https://github.com/libuv/libuv/pull/699
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
fs__realpath_handle() removes the UNC prefixes \\?\ and \\?\UNC\
from paths returned by GetFinalPathNameByHandle, but doesn't
update the string length before sending it to fs__wide_to_utf8.
Fix that by decrement the correct size from the string length.
PR-URL: https://github.com/libuv/libuv/pull/733
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
If an API function returns UV_ENOBUFS make sure we count the terminating
null, which we need space for. In case of success the null byte is not
included in the count, but the buffer *is* null terminated.
PR-URL: https://github.com/libuv/libuv/pull/690
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
libuv has multiple functions which return buffers. Make them consistent
with the following rules: the returned size *does not* include the null
byte, but the buffer *is* null terminated.
There is only one exception to the above: Linux abstract sockets,
because null bytes are not used as string terminators in those.
Refs: https://github.com/libuv/libuv/pull/674
PR-URL: https://github.com/libuv/libuv/pull/690
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
On Windows the pipe implementation could read more from a stream than
was available and it would create an assertion failure. This change
will make it so we read the minimum of the available data or the length
of the data.
To test this, I took the existing ipc_send_recv_tcp test and updated it
to do two writes and two read on each side of the pipe since that was the
reproduction recipe used by the reporter. This approach reproduced the
issue on Windows and the committed fix resolved the issue.
Fixes: https://github.com/libuv/libuv/issues/505
PR-URL: https://github.com/libuv/libuv/pull/549
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Previous behavior on Windows was to set the path to NULL for removed
and renamed fs events. This was because the path provided by
ReadDirectoryChangesW might (in rare cases) be an 8.3 short name which
could then no longer be converted to a long name after the path had
been removed or renamed. This meant that the user had to detect which
path was actually deleted or renamed and required the user to rescan
the entire watched subtree, taking several seconds or more for large
subtrees.
However, ReadDirectoryChangesW is publicly documented to emit 8.3
short names if the original handle for the changed path was opened
using an 8.3 short name, and libuv may already emit 8.3 short names for
other events if the path cannot be explicitly resolved to a long name.
This commit fixes the path for removed and renamed fs events, and does
not set the path to NULL, even if the path might be an 8.3 short name.
This makes it possible for the user to do a partial scan of the
subtree, restricting the scan to paths which match the long form or 8.3
short name (even if some of these are false positive matches). This
means that deletes and renames can now be detected accurately on
Windows within a few milliseconds.
Fixes: https://github.com/libuv/libuv/issues/634
Refs: https://github.com/libuv/libuv/pull/199
PR-URL: https://github.com/libuv/libuv/pull/639
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Equivalent to realpath(3), returns the full resolved absolute path of a
file or directory.
PR-URL: https://github.com/libuv/libuv/pull/531
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Previously, libuv didn't return the correct error code when attempting
to close an invalid file descriptor with `uv_fs_close()`.
PR-URL: https://github.com/libuv/libuv/pull/613
Reviewed-by: Bert Belder <bertbelder@gmail.com>
When duplicating the socket handle being sent the target process
id is defaulted to the current process id. This enables uv_write2
to be used for thread-clustering in addition to process-clustering on
multi-threaded programming languages.
The ipc tests are updated to run in two modes. In the _inproc mode
the echo work is done on a second thread instead of in a second
process.
An internal function int uv_current_pid() is added to the windows
specific code which caches the value of GetCurrentProcessId(). This
means uv_write2 does not call GetCurrentProcessId() every inprocess
send.
Refs: https://github.com/joyent/libuv/issues/926
PR-URL: https://github.com/libuv/libuv/pull/540
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
They're no longer needed, since the Windows-native SRWLock functions are
no longer used.
PR-URL: https://github.com/libuv/libuv/pull/525
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Previously, on Windows Vista and later, we'd use the Windows native
SRWLock APIs. However they turned out to be semantically incompatible
with pthread read-write locks and/or plain buggy. This patch makes sure
that the custom implementation that was previously only used on old
Windows versions is now used everywhere.
This patch fixes a number of issues with the old fallback
implementation. Specifically:
* The reader count would not be incremented when a thread successfully
acquired a read lock while another thread *also* held a read lock.
* `uv_rwlock_tryrdlock()` and `uv_rwlock_trywrlock()` now
consistently return UV_EBUSY when a lock couldn't be acquired.
* Any unexpected errors now cause libuv to abort, with the exception of
`uv_rwlock_init()`.
See also https://github.com/libuv/libuv/issues/515.
PR-URL: https://github.com/libuv/libuv/pull/525
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Fold EAGAIN into EBUSY, and make it the only acceptable error.
PR-URL: https://github.com/libuv/libuv/pull/535
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Before this patch an uv_mutex_t (backed by a critical section) could be
released by a tread different from the thread that acquired it, which is
not allowed. This is fixed by using a semaphore instead.
Note that the affected code paths were used on Windows XP and Windows
Server 2003 only.
Fixes: https://github.com/libuv/libuv/issues/515
PR-URL: https://github.com/libuv/libuv/pull/516
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
\r is a single carriage return without line feed on all platforms,
including Windows.
PR-URL: https://github.com/libuv/libuv/pull/472
Reviewed-By: Bert Belder <bertbelder@gmail.com>
It's an error to do so, so just ignore it. The test would cause an
invalid memory access if the fix is undone.
PR-URL: https://github.com/libuv/libuv/pull/488
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
On Windows we create multiple pipe handles (system handles) which are
attached to pending accept requests. Each of these will take turns in
replacing the reference in handle->handle, so make sure we allow for
that **only** for pipe servers.
PR-URL: https://github.com/libuv/libuv/pull/488
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
On pipe servers handle->handle takes turns between the different server
handles, so after closing all of them just reset the dandling reference.
PR-URL: https://github.com/libuv/libuv/pull/488
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Makes uv_loop_init return an error code instead of aborting.
Currently uv_loop_init aborts if there are insufficient resources
available. As a user I want to be able to check the return code from
uv_loop_init and decide how I respond rather than having my process die.
PR-URL: https://github.com/libuv/libuv/pull/405
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Use the console text color set by the user rather than assuming the
Windows default (white foreground on black background).
PR-URL: https://github.com/libuv/libuv/pull/431
Reviewed-By: Bert Belder <bertbelder@gmail.com>
