First of all, a bit of explanation of what happens there:
1. FSEvents emits absolute paths to changed files or directories
2. We cut off the first part of such paths, which is equal to handle's
real path ('/dir/subdir/subsubdir`, without trailing slash)
3. Then, if we are running in non-recursive mode, we discard paths that
have slashes ('/') as a non-first character in them
Fix a bug that was introduced in commit 3ee4d3f ("unix, windows:
return error codes directly") and add a regression test for good
measure.
Hat tip to Fedor for pointing out the issue.
Fixes#1007.
Print the error message rather than just the errno. The fact that the
errno is 24 is only informative to people that have their operating
system's error codes memorized.
Set the close-on-exec flag on file descriptors that we've received with
recvmsg() so we don't leak them when calling fork() afterwards.
On Linux, we use the MSG_CMSG_CLOEXEC flag when supported (2.6.23 and
up.)
On older Linux versions and other platforms, we walk the received file
descriptors and set the close-on-exec flag for each fd manually. That
won't entirely avoid race conditions when other threads call fork() or
clone() but at least we're less likely to leak file descriptors now.
When fd is closed and new one (with the same number) is opened inside
kqueue/epoll/port loop's callback - stale events might invoke callbacks
on wrong watchers.
Check if watcher was changed after invocation and invalidate all events
with the same fd.
fix#826
Otherwise `FSEventStreamCreate()` will coalesce events, even if they're
happening in the interval, bigger than supplied `latency`. In other
words, if this flag is not set events will happen in separate callback
only if there was a delay bigger than `latency` between two consecutive
events.
Drop the _CRT_NON_CONFORMING_SWPRINTFS hack and just use _snwprintf().
It's a long and complicated story but the gist of it is that the MS CRT
had a swprintf() function before ISO C did, with a different function
prototype to boot: the ISO C one takes a |size| argument, the MS one
does not.
The function prototype that's exported by mingw and mingw-w64 depends
on the mingw version and the _CRT_NON_CONFORMING_SWPRINTFS define.
If they don't match up, you get the wrong prototype and things will
crash at run-time.
Reduce the phase space by sidestepping the whole issue: drop swprintf()
altogether and use _snwprintf() from now on.
Fixes#990.
Work around an epoll quirk where it sometimes reports just the EPOLLERR
or EPOLLHUP event. In order to force the event loop to move forward,
we merge in the read/write events that the watcher is interested in;
uv__read() and uv__write() will then deal with the error or hangup in
the usual fashion.
Fixes#982.
This is a back-port of commit 24bfef2 from the master branch.
Work around an epoll quirk where it sometimes reports just the EPOLLERR
or EPOLLHUP event. In order to force the event loop to move forward,
we merge in the read/write events that the watcher is interested in;
uv__read() and uv__write() will then deal with the error or hangup in
the usual fashion.
Fixes#982.
Create file paths with CFStringCreateWithFileSystemRepresentation(),
not CFStringCreateWithCString().
Reapplies 3780e12 ("fsevents: support japaneese characters in path")
from the v0.10 branch. Was dropped in the last v0.10 -> master merge
for failing to apply.
Drops commit 3780e12 ("fsevents: support japaneese characters in path")
for being quite inapplicable to the master branch. Will be reworked
and applied in a follow-up commit.
Conflicts:
README.md
build.mk
src/unix/fsevents.c
src/unix/udp.c
If spawning a process fails due to an exec() failure (but it succeeded
in forking), then this should be considered a spawn failure instead of
an asynchronous termination of the process. This allows to check for
common exec() failure conditions such as a bad path quickly instead of
having to rely on keeping track of the async callback.
Additionally, the meaning of the two fields returned in the callback are
now exactly what they advertise to be. The process exit argument is not
one of two values depending on what happened to the child.
Fixes#978.
Rewrite some of the macros in a way that:
a) makes them more likely to trigger compile-time errors if used
inappropriately, and
b) makes C++ compilers happy
On the BSDs, SO_REUSEPORT is pretty much SO_REUSEADDR with some special
casing for IP multicast. When two processes (that don't do multicast)
bind to the same address, only the last one receives traffic. It allows
one to "steal" the bound address from another process. (Both processes
have to enable SO_REUSEPORT though, so it only works in a cooperative
setting.)
On Linux however, it enables port sharing, not stealing - both processes
receive a share of the traffic. This is a desirable trait but pre-3.9
kernels don't support the socket option and a libuv program therefore
behaves differently with older kernels or on another platform.
This is a back-port of commit 9d60f1e from the master branch.
Fixesjoyent/node#6454.
Watchers could be stopped between two `kevent()`/`epoll_wait()` calls
(which may happen in the same loop in `uv__io_poll()`), in such cases
`watcher->events` could be stale and won't be updated to
`watcher->pevents`.
Try to use and rely on `watcher->pevents` instead of blindly expecting
`watcher->events` to be always correct.
On some systems, clock_gettime(CLOCK_MONOTONIC) is only serviced from
the vDSO when the __vdso_clock_gettime() wrapper is confident enough
that the vDSO timestamp is highly accurate. When in doubt, it falls
back to making a traditional SYS_clock_gettime system call with all
the overhead that entails.
While a commendable approach, it's overkill for our purposes because we
don't usually need high precision time. That's why this commit switches
to CLOCK_MONOTONIC_COARSE for low-precision timekeeping, provided said
clock has at least a one millisecond resolution.
This change should eliminate the system call on almost all systems,
including virtualized ones, provided the kernel is >= 2.6.32 and glibc
is new enough to find and parse the vDSO.
Cheking if the loop is alive is covered in the while loop afterwards.
Also, the stop flag will be cleared if necessary, which didn't happen
before this patch.
Mea culpa, the previous commit added another ERROR_FILENAME_EXCED_RANGE
case to the switch statement in uv_translate_sys_error(). This commit
fixes up the build error.
Make it possible to call uv_tty_reset_mode() from inside a signal
handler. The primary motivation is to make it possible to restore
the TTY from inside a SIGINT or SIGTERM signal handler.
Fixes#954.
