Rather than aborting in the face of *any* repeated link in a given path,
instead only abort if such a cycle actually makes a given path unresolvable.
Test for this by doing a normal stat. Still use the seenLinks object to
cache link contents so as to cut own a little bit on readlink calls.
Also add a pathological test that fails without the change to fs.js.
Users too often would forget to add
socket.on('end', function () {
socket.end();
});
Which is a mistake. Therefore we default to this behavior and
only optionally let people handle the 'end' case themselves.
Mostly just upgraded tools/test.py to the latest one that's in V8. But also
fixing the before and after hooks to preserve the test/tmp directory so that
running tests manually usually works.
Originally written to try to track down this bug report:
http://permalink.gmane.org/gmane.comp.lang.javascript.nodejs/13924
As it turns out, it's showing a completely different kind of failure. When
the file is base64 encoded with the native program, then decoded with node,
it doesn't match the original. Something's fishy.
There are a few kinds of errors that are very confusing.
1. Errors raised in nextTick
2. Errors emitted on the "error" event
3. RangeErrors that crash the program (or anything without a stack trace)
Long traces will make make these better, of course. In the meantime, this
adds a few handy signposts (in the form of better error reporting and
comments on the otherwise inscrutable code printed to the terminal) that can
help new users find the cause, or at least, ask for help more effectively.