All compile time warnings about using deprecated APIs have been
suppressed by updating node's API. Though there are still many function
calls that can accept Isolate, and still need to be updated.
node_isolate had to be added as an extern variable in node.h and
node_object_wrap.h
Also a couple small fixes for Error handling.
Before v8 3.16.6 the error stack message was lazily written when it was
needed, which allowed you to change the message after instantiation.
Then the stack would be written with the new message the first time it
was accessed. Though that has changed. Now it creates the stack message
on instantiation. So setting a different message afterwards won't be
displayed.
This is not a complete fix for the problem. Getting error without any
message isn't very useful.
Commit a804347 makes fs function rethrow errors when the callback is
omitted. While the right thing to do, it's a change from the old v0.8
behavior where such errors were silently ignored.
To give users time to upgrade, temporarily disable that and replace it
with a function that warns once about the deprecated behavior.
Close#5005
Now that highWaterMark increases when there are large reads, this
greatly reduces the number of calls necessary to _read(size), assuming
that _read actually respects the size argument.
Ability to return just the length of listeners for a given type, using
EventEmitter.listenerCount(emitter, event). This will be a lot cheaper
than creating a copy of the listeners array just to check its length.
This makes it so that `stream.push(chunk)` is the only way to signal the
end of reading, removing the confusing disparity between the
callback-style _read method, and the fact that most real-world streams
do not have a 1:1 corollation between the "please give me data" event,
and the actual arrival of a chunk of data.
It is still possible, of course, to implement a `CallbackReadable` on
top of this. Simply provide a method like this as the callback:
function readCallback(er, chunk) {
if (er)
stream.emit('error', er);
else
stream.push(chunk);
}
However, *only* fs streams actually would behave in this way, so it
makes not a lot of sense to make TCP, TLS, HTTP, and all the rest have
to bend into this uncomfortable paradigm.
It seems like a good idea on the face of it, but lowWaterMarks are
actually not useful, and in practice should always be set to zero.
It would be worthwhile for writers if we actually did some kind of
writev() type of thing, but actually this just delays calling write()
and the overhead of doing a bunch of Buffer copies is not worth the
slight benefit of calling write() fewer times.
This increases fs.WriteStream throughput dramatically by removing the
"higher default water marks" for fs.WriteStream.
Also includes a benchmark. Current performance is significantly higher
than v0.8 for strings at all tested levels except size=1. Buffer
performance is still lackluster.
Further improvement in the stream.Writable base class is required, but
this is a start.
Fix an exception that was raised when the WriteStream was closed
immediately after creating it:
TypeError: Cannot read property 'fd' of undefined
at WriteStream.close (fs.js:1537:18)
<snip>
Avoid the TypeError and make sure the file descriptor is closed.
Fixes#4745.
Make `fs.createReadStream({ end: 42 })` work.
Before this commit, it worked only when used like this:
`fs.createReadStream({ start: 0, end: 42 })` - only when `start` was specified
by the caller.
Fixes#4423.
Enable long stacktraces if NODE_DEBUG=fs is set in the environment. Only
applies to the default rethrow callback; it's to help you find places where
you forgot to pass in a callback.
Use a default callback if the user omitted one. Avoids errors like the one
below:
fs.js:777
if (err) return callback(err);
^
TypeError: object is not a function
at fs.appendFile (fs.js:777:21)
at Object.oncomplete (fs.js:297:15)
This commit fixes the behavior of fs.lchmod(), fs.lchown() and fs.readFile()
when the callback is omitted. Before, they silently swallowed errors.
Fixes#4352.
Make sure the deletion event gets reported in the following scenario:
1. Watch a file.
2. The initial stat() goes okay.
3. Something deletes the watched file.
4. The second stat() fails with ENOENT.
The second stat() translates into the first 'change' event but a logic error
stopped it from getting emitted.
Fixes#4027.
Fixes a minor oversight introduced in 168a555, resulting in the following error:
fs.js:467
return fs.ftruncateSync(path, len, callback);
^
ReferenceError: callback is not defined
at Object.fs.truncateSync (fs.js:467:40)
The destroy() method of fs.ReadStream and fs.WriteStream takes a callback.
It's a leftover from the node 0.1 days, undocumented and not part of the
streams API. Remove it.
Before this commit, `fs.unwatchFile(path)` removed *all* listeners for `path`.
The function is overloaded now: `fs.unwatchFile(path)` still removes all
listeners, but `fs.unwatchFile(path, cb)` lets you remove a specific listener.
Fixes#3660.
There is no need for fs.readFile() to be using pread rather than read.
The default semantics of read() are such that subsequent reads are where
we want them anyway.
Also, in the process, fix a bug in fs.realpath on Windows.
If the user has permission to create symlinks, then use symlinks. If
not, then skip over all the tests that cannot be run using Junctions
instead.
Raymond Feng
Trevor Norris
isaacs
Ben Noordhuis
Shigeki Ohtsu
Farid Neshat
Bert Belder
Gil Pedersen
Andreas Madsen