Some test errors from an Ubuntu 14.04 64bit machine

[Fishrock123]

I'm helping @aks- get started to contributing to node; he reported these errors to me on IRC from his Ubuntu 14.04-64bit machine, which I haven't seen reported before.

=== release test-fs-long-path ===                                              
Path: parallel/test-fs-long-path
{ filenameLength: 260, fullPathLength: 260 }
/home/ashok/myprojects/io.js/test/parallel/test-fs-long-path.js:22
  if (err) throw err;
                 ^
Error: ENAMETOOLONG: name too long, open '/home/ashok/myprojects/io.js/test/tmp.2/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
    at Error (native)
Command: out/Release/iojs /home/ashok/myprojects/io.js/test/parallel/test-fs-long-path.js

=== release test-require-long-path ===                                         
Path: parallel/test-require-long-path
fs.js:799
  return binding.mkdir(pathModule._makeLong(path),
                 ^
Error: ENAMETOOLONG: name too long, mkdir '/home/ashok/myprojects/io.js/test/tmp.0/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
    at Error (native)
    at Object.fs.mkdirSync (fs.js:799:18)
    at Object.<anonymous> (/home/ashok/myprojects/io.js/test/parallel/test-require-long-path.js:16:4)
    at Module._compile (module.js:430:26)
    at Object.Module._extensions..js (module.js:448:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Function.Module.runMain (module.js:471:10)
    at startup (node.js:117:18)
    at node.js:948:3
Command: out/Release/iojs /home/ashok/myprojects/io.js/test/parallel/test-require-long-path.js

=== release test-net-better-error-messages-port-hostname ===                   
Path: parallel/test-net-better-error-messages-port-hostname
Command: out/Release/iojs /home/ashok/myprojects/io.js/test/parallel/test-net-better-error-messages-port-hostname.js
--- TIMEOUT ---

=== release test-net-connect-immediate-finish ===             
Path: parallel/test-net-connect-immediate-finish
Command: out/Release/iojs /home/ashok/myprojects/io.js/test/parallel/test-net-connect-immediate-finish.js
--- TIMEOUT ---

(dunno who to cc)

[rvagg]

I'm pretty sure that'd be from using ecryptfs which has absurd path length limitations and causes these kinds of problems. grep ecrypt /etc/mtab and see if that corresponds to the path being used.

[Fishrock123]

Ah, yes, looks like that was the issue. Thanks.

[rsp]

@Fishrock123 @aks- Try building Node in /tmp/node or somewhere else outside /home

@rvagg Does Node really need so long path names to run correctly? So far the only indication that I have absurd path length limitations on my file system was Node's make test failing. I wonder why is such a test there in the first place. Is it really needed to test whether Node compiled correctly?

[rvagg]

@rsp context for that test is here: #1991 — I'd be open to supporting a PR that can make it optionally run in environments where it can't run, like ecryptfs, but I'm not really sure how or even if that can be achieved.

The long pathname issue is what made me stop using ecryptfs and go with full disk encryption on Linux instead. It bit me with more than just Node.

[rsp]

@rvagg I prepared a PR #3925 that fixes this issue.

It changes only those two tests that fail on ecryptfs file systems (test-fs-long-path.js and test-require-long-path.js) so that they make their files under /tmp - actually, os.tmpdir() - but only on Linux and only when it verifies that it can create a directory there. Otherwise (i.e. not on Linux or if it can't create directory in /tmp) it works the same as before my changes.

If you think it is not how it should work and it should try to create files under /tmp only when the current tests fails, please let me know so I prepare a new PR. Thanks.

I think this fix is important because even though it is not Node's fault that ecryptfs has those limitations, the fact is that people still use ecryptfs on default installs of Ubuntu and for them it looks like Node is broken, not ecryptfs. I actually found this issue when someone told me that he can't compile Node because tests fail and refused to make install a build with failing tests. Building it all under /tmp helped but many people building Node on Ubuntu may have a bad impression of Node after seeing failed tests.

[rsp]

@Fishrock123 I think the wontfix label be removed after commit 0c2a0dc - see PR #4116