Retry long path tests on Linux under real tmp dir

[rsp]

Use os.tmpdir() on Linux if it is readable/writable
but only when the original tests fail
in test-fs-long-path.js and test-require-long-path.js
to avoid failing tests on ecryptfs filesystems
See issue #2255 and comments to PR #3925

[rvagg]

use a template string to shorten this

[rvagg]

https://ci.nodejs.org/job/node-test-pull-request/793/

I think as long as you're basically rewriting all of this you may as well replace all the vars with const and let where appropriate

[rsp]

@rvagg Good point. I used template strings and changed vars to const in fa83454 - should a new PR with a single commit be created or is it ok as it is?

[rvagg]

lgtm pending https://ci.nodejs.org/job/node-test-pull-request/794/

@rsp squash the commits into one and follow the format outlined in https://github.com/nodejs/node/blob/master/CONTRIBUTING.md#step-3-commit for the message.

[rsp]

@rvagg New PR with one commit: #3936

[targos]

@rsp you didn't have to create a new PR. You can force push to the same branch to update this one.

[rvagg]

Using git push remotename branchname --force, also if you need help squashing then have a poke around in git rebase -i HEAD~2 to see your last 2 commits on the branch, the -i enters into an interactive mode where you can choose from a bunch of handy options to rearrange and edit your commits. So normally you should only need a single PR and you just mess with your branch.

Another less elegant way to do this is to delete or rename your local copy of this branch, make a new one and do what you need on it and use --force to push it your github fork and it'll end up here.

[rsp]

@targos@rvagg Thanks for the advice, I thought that I should avoid force pushing to public repos but if that's ok for you then I'll do that in the future. Sorry for causing a mess and thanks for your help and patience, this is my first contribution to Node.

[rvagg]

No problems @rsp, you'd actually be force pushing to your own fork so that doesn't create any hassles on this end. Thanks for the contribution and presuming this lands without objection in a day or two, welcome to the club of contributors, hopefully we'll be seeing more from you!

[rsp]

@rvagg My pleasure, thanks for your help. I hope I'll be able to contribute something useful. By the way, those two tests that I was working with were just throwing exceptions and printing long stack traces so I had to find the relevant lines in source code to see what's going on. I kept it that way but maybe it would be useful to print a more meaningful message instead of the stack trace in those two or other similar tests? I don't know if there is any guide for writing good tests that describes how a good output should look like, I haven't found it in CONTRIBUTING.md or COLLABORATOR_GUIDE.md. Maybe there is some room for improvement to make tests print few lines of relevant info instead of stack traces? If so, I'll be happy to help with that.

[jbergstroem]

An alternative to this would be changing path to tmpdir (#3325) but having a default state of "Just Working" is nice. LGTM.

[jbergstroem]

perhaps use process.platform == 'linux' instead?

[rsp]

@jbergstroem Yes, it would be the same. This code already uses the os module for other things so it seemed to make sense to use the normalized name for the comparison but it could test process.platform or os.platform() just as well as os.type(). I can change it if that's what's holding the PR #3936 back.

[bnoordhuis]

process.platform is a little more idiomatic, at least w.r.t. to the test suite.

[rsp]

@bnoordhuis@jbergstroem Done. It's using process.platform now. See: 2f5ca5d

[rsp]

@jbergstroem changing path to tmpdir would be perfect - much better than what I did here. This was actually the first thing that I tried but changing exports.tmpDir in test/common.js broke so many tests that I gave up and used a solution that changes the behavior of just two tests without messing with something like 138 places where the tmpDir is used.

But I agree that optionally changing the temp dir for all tests would be much better and breaking so many tests by changing it is probably a sign of a more serious problem (having tmp.0, tmp.1, tmp.2, tmp.3, tmp.4, tmp.5, tmp.6, tmp.7 directories left in test after make test may be a clue on why is that but that may not be the only problem).

[jbergstroem]

@rsp I have a few fixes I will push to PR in a day or three. Feedback appreciated!

[rsp]

@jbergstroem Great, thanks. By the way, I created a new PR #3936 - see comments above. It is the same as this one but with one commit as suggested in the comments here. (I didn't know that the practice here is to force push squashed commits to public PR branches, so I thought I need to create a new PR with squashed commits to avoid losing diff comments like yours.)

[jbergstroem]

@rsp no need to squash until its ready for merge.

[rsp]

@jbergstroem OK, maybe I misunderstood the previous comments. This is my first contribution here so I'm still learning how things work here. Thanks for your help.

[rsp]

@jbergstroem You said about fixes to this PR that you want to push a week ago. If you don't have time then let me know what needs to be fixed and I'll change it. Thanks.

[bnoordhuis]

I'm not sure if I'm okay with adding hacks for something as niche as ecryptfs, the more so because the workaround is quite involved.

[rsp]

@bnoordhuis This test is made for Windows. You don't really have to test long path support on Linux to see if the long path support is working correctly in Node - you only have long/short path issues on Windows. The problem is that those two tests while reasonable on Windows fail on default Ubuntu installations that makes the entire Node look like it hasn't compiled correctly and if you run make && make test && make install it fails. In my opinion make test shouldn't fail when the compilation was successful but happened in the "wrong" directory, but if you think it should be solved differently then please let me know. Also @jbergstroem has some fixes for this PR but I don't know what those are yet.

[bnoordhuis]

Wouldn't it make more sense in that case to skip the test when process.platform !== 'win32'?

[jbergstroem]

@rsp my fixes aren't for this PR, rather for the one I linked (#3325).

[rsp]

@bnoordhuis Maybe but I thought that running the test would be more preferable than skipping it, to make sure that it is indeed just the wrong place to run it instead of lacking the required functionality. What I did is to run it in real system tmp if it fails in $PWD but as always there's more than one way to do it. If there is consensus on how it should be done differently then I will be happy to change it but I thought @rvagg and @targos were ok with how it is done right now so I don't want to skip the test entirely without hearing their opinion first.

[rsp]

@jbergstroem Sorry, I misunderstood you. I hope your PR gets support and the system temp dir will be the default temp path for Node tests.

[jbergstroem]

@rsp fyi I won't change defaults - there'll probably be too many problems with that (esp cross-filesystem issues).

[rsp]

@jbergstroem Oh, I see. So unfortunately we would still need this PR (or skipping those two tests entirely on Linux as suggested by @bnoordhuis) to have the tests work on Ubuntu.

Personally I can live with those tests failing because I can always inspect the stack trace every time I run make test to see if only those two tests failed or maybe some other ones that are important but for some people "make test fails" == "software is broken" and it makes Node look broken, which is unfortunate.

[jbergstroem]

@rsp; not really -- you'd pass NODE_TEST_DIR=/tmp/foo make check

[jasnell]

Any updates on this one?

[rsp]

@jasnell The issue #2255 was closed by pr #4116 which doesn't really fix those tests but skips them instead (personally I'd prefer running the corrected tests that work fine instead of skipping them but at least now make test works on Ubuntu by default so it's better than nothing) so I think I can close this pr. Thanks for the reminder. Please let me know if I should add/remove any labels as well.