Implemented a new property for writable file streams that keeps track
of the bytes written (not queued). This helps when you are piping
another stream to a file, and would like to know how big the file is
without having to issue another stat call.
closes#930
When creating multiple .pipe()s to the same destination stream, the
first source to end would close the destination, breaking all remaining
pipes. This patch fixes the problem by keeping track of all open
pipes, so that we only call end on destinations that have no more
sources piping to them.
closes#929
Previously the return value of write was dependent on if it was paused or
not which was causing a strange error demoed in the previous commit.
Fixes#892
Also, secureOptions flag was added (and passed through) and allows
the context to have all supported SSL_OP_* set via createCredentials.
All SSL_OP_ flags (outside of ALL) have been added to constants.
Cherry-pick fail. Breaks linux. Will land again shortly.
This reverts commit e8cf98c841.
This reverts commit d953856d87.
This reverts commit 752bbd6b42.
Problem: Sometimes it is useful to read a file from a certain position
to it's end. The current implementation was already perfectly capable
of this, but decided to throw an error when the user tried to omit
the end option. The only way to do this, was to pass {end: Infinity}.
Solution: Automatically assume {end: Infinity} when omitted, and remove
the previous exception thrown. Also updated the docs.
closes#801.
However, this test is failing for some quite unrelated issue.
Getting some odd "socket hangup" crashes, and only the first request
ever makes it to the server.
Calling resume() immediately after calling pause() would trigger
a race condition where it would try to read() from a file
descriptor that was already being read from, causing an EBADF