Is your feature request related to a problem? Please describe.
People sometimes will encounter the error that System limit for number of file watchers reached.. If we enable users to add hooks in fs.statWatchers, they could track the codes that which module call fs.watchFile many times
Describe the solution you'd like
const { statWatchers, watchFile } = require(‘fs’)
statWatchers.on(‘statAdd’, () => {})
statWatchers.on(‘statRemove’, () => {})
watchFile(‘xxx‘, () => {})
Related code
https://github.com/nodejs/node/blob/9949a2e1e3100c4ff1f228bac57c1af95cdc3e9d/lib/fs.js#L1458
I think this feature would be necessary
In Linux or other platforms, the file watcher is very expensive resources for user. For example, there are some limit about file watcher count for the unique user id in Linux
So I think it would be necessary to allow people get a way to trace/output log/do other things meaningful for their 'file watch' action
If we enable users to add hooks in fs.statWatchers, they could track the codes that which module call
fs.watchFilemany times
Two questions:
fs.watch() only? The stat watchers shouldn’t count towards a global limit?fs.watch() and fs.unwatch() if this is what you’re looking for?Doesn’t this happen with fs.watch() only? The stat watchers shouldn’t count towards a global limit?
Yes, it do is the global limit, but sometimes we need to monitor which module reach the limit.
Doesn’t it suffice to override/wrap fs.watch() and fs.unwatch() if this is what you’re looking for?
I noticed that we already have fs. statWatchers using Map, to memory the stats. What about we enhance it to the EventEmitter or anything else, not just a third part module to achieve this.
Doesn’t this happen with fs.watch() only? The stat watchers shouldn’t count towards a global limit?
Yes, it do is the global limit, but sometimes we need to monitor which module reach the limit.
I don’t really understand how this relates to the difference between fs.watch() and fs.watchFile()? fs.watchFile() does not take up OS resources, as I understand it.
Doesn’t it suffice to override/wrap fs.watch() and fs.unwatch() if this is what you’re looking for?
I noticed that we already have
fs. statWatchersusing Map, to memory the stats. What about we enhance it to theEventEmitteror anything else, not just a third part module to achieve this.
I guess to be more explicit, what is the advantage of using an EventEmitter here, as opposed to keeping the API surface as it is?
Most helpful comment
I don’t really understand how this relates to the difference between
fs.watch()andfs.watchFile()?fs.watchFile()does not take up OS resources, as I understand it.I guess to be more explicit, what is the advantage of using an
EventEmitterhere, as opposed to keeping the API surface as it is?