You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fs.createWriteStream does not fire close event #21122
@joyeecheung it does to me as well, but the 'close' event for the WriteStream class is actually documented in the fs docs, and is inherently tied to the filesystem:
Emitted when the WriteStream's underlying file descriptor has been closed.
Therefore, I thought it'd be a filesystem bug. Will try "inspect"-ing this tomorrow, if I can.
I came across this issue on trying to upgrade to node 10. The code snippet is extracted and simplified from a npm package which refuses to work with node 10 but worked well until then.
I personally prefer the code as outlined by @DaAitch.
Yes indeed using readable with once solves the problem. Thanks.
I've also run into this issue. Is it expected? Our motivation is to use the stream with a Node.js Console object, where we'd leave the stream open for the (long) lifetime of the application, during which logrotate or similar may remove the underlying file. However, we get no event in this case.
conststream=fs.createWriteStream('out.log',{flags: 'a'});constlogger=newConsole(stream);// Doesn't seem to fire?stream.on('close',()=>console.log('CLOSED');logger.log('foo');// This might be done by an external app for examplefs.unlinkSync('out.log');logger.log('bar');
Unlinking a file removes its name from the parent directory, but doesn't remove the file. any open references to it remain open. You will need to periodically close and reopen the file. I wouldn't recommend building this yourself, use winston, pino, log4j or bunyan.
Activity
DaAitch commentedon Jun 5, 2018
I can confirm that behaviour although I don't know if it's correct or not. Different versions have different outputs.
versions I used:
I've also tested it the easier way of "copying via stream" and it works as expected, both close events are emitted.
ryzokuken commentedon Jun 5, 2018
Strange. There don't seem to be any changes made in particular:
@nodejs/fs any idea what's going on here?
joyeecheung commentedon Jun 5, 2018
@ryzokuken This looks more like a stream issue rather than fs issue?
ryzokuken commentedon Jun 5, 2018
@joyeecheung it does to me as well, but the
'close'event for theWriteStreamclass is actually documented in the fs docs, and is inherently tied to the filesystem:Therefore, I thought it'd be a filesystem bug. Will try "inspect"-ing this tomorrow, if I can.
mcollina commentedon Aug 21, 2018
This is not a bug. This behavior was changed in #18994.
@spurreiter I'm not really understading why are you deferring piping in #21122 (comment). Could you please articulate your use?
Side note, this should work (note that we are listening for the
'readable'event only once:cc @oyyd
spurreiter commentedon Sep 16, 2018
I came across this issue on trying to upgrade to node 10. The code snippet is extracted and simplified from a npm package which refuses to work with node 10 but worked well until then.
I personally prefer the code as outlined by @DaAitch.
Yes indeed using
readablewithoncesolves the problem. Thanks.alecgibson commentedon Oct 14, 2019
I've also run into this issue. Is it expected? Our motivation is to use the stream with a Node.js
Consoleobject, where we'd leave the stream open for the (long) lifetime of the application, during whichlogrotateor similar may remove the underlying file. However, we get no event in this case.sam-github commentedon Oct 14, 2019
Unlinking a file removes its name from the parent directory, but doesn't remove the file. any open references to it remain open. You will need to periodically close and reopen the file. I wouldn't recommend building this yourself, use winston, pino, log4j or bunyan.