test: refactor test-fs-watchfile.js

[Trott]

The test no longer waits about 5 seconds between callback invocations. On my laptop, the test had been taking over 5 seconds to run. Now it takes less than 150ms.

The test had also been writing to and deleting from the fixtures directory. It now uses the tmp directory instead.

(An aside: Does anyone know why the Python test wrapper uses duration_ms for durations that are in seconds and not milliseconds? Is that a straight up error or am I just misunderstanding the ms part? This has been bugging me for a long time, but I'm not sure what unintended consequences might lurk if we slice off the _ms or change it to just _s. It seems like there might be some CI or smoke test stuff that expects specific strings and whatnot.)

[Trott]

CI: https://jenkins-iojs.nodesource.com/job/node-test-commit/173/

EDIT: Or is the right link for CI in this case https://jenkins-iojs.nodesource.com/job/node-test-pull-request/96/ ? Either way, full green, woot.

[brendanashworth]

Just wondering, how does an interval of zero work?

[Trott]

I figured that would poll every time the event loop finished. Ultimately, interval gets passed to libuv's uv_fs_poll_start(). Judging from this line of code it seems that 0 gets changed to 1. Correction or confirmation on my interpretation would be very welcome.

[Trott]

I suppose the whole "what happens if you set interval to 0" thing should be covered in the docs. /cc @nodejs/documentation

[bnoordhuis]

Technically correct, although libuv may change it someday to mean the lowest supported or most optimal poll interval. From the manual:

For maximum portability, use multi-second intervals. Sub-second intervals will not detect all changes on many file systems.

[rvagg]

re duration_ms being in seconds: I went down that rabbit hole recently and can't recall exactly where I landed but I think it's actually referring to the "duration in seconds, including milliseconds" rather than "duration in milliseconds".

[bnoordhuis]

This change is probably fine to land (CI is happy) but it may break the test locally for some people if their file system doesn't support sub-second file timestamps.

[Trott]

I don't think it will break on systems that don't support sub-second timestamps because current timestamps don't enter into the test.

0 (er... 1) is the polling interval. The first time the file is polled, ENOENT results and the callback is fired. This is the only time that timestamps are checked and all that is checked is that the timestamps are set to the start of the Unix Epoch. The callback then creates the file.

The next time the file is polled, there's something there so the callback fires again because whatever comes back from fstat() or whatever is different than ENOENT. This time, the callback does not check any timestamps. Instead, the inode count is checked to confirm that the file exists.

[bnoordhuis]

Now that you bring it up... that sounds about right. LGTM then.

[thefourtheye]

LGTMT

[Trott]

Landed in 522f8a8