test: make test-fs-watch-recursive more robust

[Trott]

Checklist

• make -j8 test (UNIX), or vcbuild test nosign (Windows) passes
• commit message follows commit guidelines

Affected core subsystem(s)

test fs

Description of change

The test was failing on OS X when run in parallel with:

tools/test.py --repeat=99 -J parallel/test-fs-watch-recursive

ENOENT was arising when trying to create a file in the directory created
with fs.mkdtempSync(). I do not know if this is a bug in OS X, a bug
in libuv, or something else. I also do not know this is partially or
completely the cause of the flakiness of the test in CI and locally
(when run as part of make test).

In any event, changing to fs.mkdirSync() resolved the issue.

/cc @nodejs/testing

[Trott]

@santigimeno has done some looking into this and it looks like this fix is misguided. I've added the in progress label for now. It looks like this is probably a bug in either common.js or test.py, or else a misunderstanding on my part. It looks like test.py -J will run tests in parallel but may not guarantee that they won't share tmp directories? Or maybe a bug in common.js that has a similar-ish result?

[Trott]

I can get the error even with a --repeat value lower than -j such as:

tools/test.py -j 4 --repeat=3 parallel/test-fs-watch-recursive

which yields things like:

$ tools/test.py -j 4 --repeat=3 parallel/test-fs-watch-recursive
=== release test-fs-watch-recursive ===                    
Path: parallel/test-fs-watch-recursive
fs.js:557
  return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode);
                 ^

Error: ENOENT: no such file or directory, open '/Users/trott/io.js/test/tmp.3/yjbVje/watch.txt'
    at Object.fs.openSync (fs.js:557:18)
    at Object.fs.writeFileSync (fs.js:1214:33)
    at Timeout._onTimeout (/Users/trott/io.js/test/parallel/test-fs-watch-recursive.js:39:8)
    at ontimeout (timers.js:365:14)
    at tryOnTimeout (timers.js:237:5)
    at Timer.listOnTimeout (timers.js:207:5)
Command: out/Release/node /Users/trott/io.js/test/parallel/test-fs-watch-recursive.js
[00:00|% 100|+   2|-   1]: Done 
$

It also very occasionally gives me EEXISTS....

[Trott]

Seems to have to do with the interaction of the --repeat parameter with -j in test.py. This fails every time with what seems to be temp directory collisions (two tests trying to use the same tmp directory):

tools/test.py -J --repeat=10 parallel/test-fs-watch-recursive

But this seemingly equivalent command succeeds every time:

tools/test.py -J parallel/test-fs-watch-recursive parallel/test-fs-watch-recursive parallel/test-fs-watch-recursive parallel/test-fs-watch-recursive parallel/test-fs-watch-recursive parallel/test-fs-watch-recursive parallel/test-fs-watch-recursive parallel/test-fs-watch-recursive parallel/test-fs-watch-recursive parallel/test-fs-watch-recursive

/cc @nodejs/testing or maybe @nodejs/build or maybe someone whose Python-knowledgable which I think might be @thefourtheye

[Trott]

The --repeat option was added in ccbb00e so I guess I'll /cc @mhdawson too...

[Trott]

Figured it out. Closing this. PR addressing test.py issue coming momentarily.