-
Notifications
You must be signed in to change notification settings - Fork 29.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: clarify eventType in fs.watch #9318
Conversation
'rename' is confusing, and it's not clear what "they" refers to. Fixes: #9082
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few style nits that don't really matter much, but more importantly: I don't think the information about rename
is correct on all operating systems. I could be misreading what's going on, but judging from some of the tests, it appears that whether you get change
or rename
on file creation (for example) is OS-dependent. See, for example:
node/test/sequential/test-fs-watch.js
Line 83 in 6893f3c
var renameEv = common.isSunOS ? 'change' : 'rename'; |
@@ -1702,8 +1702,11 @@ The listener callback gets two arguments `(eventType, filename)`. `eventType` i | |||
`'rename'` or `'change'`, and `filename` is the name of the file which triggered | |||
the event. | |||
|
|||
Please note the listener callback is attached to the `'change'` event | |||
fired by [`fs.FSWatcher`][], but they are not the same thing. | |||
Note that `'rename'` is also emitted when a file is deleted or added - in other words, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: no hyphen. ...when a file is deleted or added. In other words, ...
Please note the listener callback is attached to the `'change'` event | ||
fired by [`fs.FSWatcher`][], but they are not the same thing. | ||
Note that `'rename'` is also emitted when a file is deleted or added - in other words, | ||
it's emitted whenever a filename appears or disappears in the directory. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: it's
-> it is
it's emitted whenever a filename appears or disappears in the directory. | ||
|
||
Also note the listener callback is attached to the `'change'` event fired by | ||
[`fs.FSWatcher`][], but it's not the same thing as the `'change'` value of `eventType`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: it's
-> it is
Fixed the nits. According to my tests, this behavior is consistent across Windows, Linux and MacOS, so I just changed it to "most platforms". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple more nits, but LGTM
@@ -1702,8 +1702,11 @@ The listener callback gets two arguments `(eventType, filename)`. `eventType` i | |||
`'rename'` or `'change'`, and `filename` is the name of the file which triggered | |||
the event. | |||
|
|||
Please note the listener callback is attached to the `'change'` event | |||
fired by [`fs.FSWatcher`][], but they are not the same thing. | |||
Note that on most platforms, `'rename'` is also emitted when a file is deleted or added. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: remove also
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I used "also" because it's in addition to being renamed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggested removing it because I think it could be interpreted to mean that both a rename
and a change
event will be emitted.
I think someone might think it means "A change event is emitted and a rename event is also emitted."
I understand that you mean it as "A rename event is emitted in this case and a rename event is also emitted in this other case."
I'm fine with leaving it the way you have it if you have a strong preference for that. But if it doesn't make much of a difference to you either way, I'd prefer it removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like with your suggestion the two sentences somewhat contradict each other...
How about a compromise? Just combine them into one sentence: "Note that on most platforms, 'rename'
is emitted whenever a filename appears or disappears in the directory."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that works for me.
Please note the listener callback is attached to the `'change'` event | ||
fired by [`fs.FSWatcher`][], but they are not the same thing. | ||
Note that on most platforms, `'rename'` is also emitted when a file is deleted or added. | ||
In other words, it is emitted whenever a filename appears or disappears in the directory. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: add on most platforms
here too to be as explicit as possible: In other words, on most platforms, it is emitted...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with a nit
or disappears in the directory. | ||
|
||
Also note the listener callback is attached to the `'change'` event fired by | ||
[`fs.FSWatcher`][], but it is not the same thing as the `'change'` value of `eventType`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: long line here.
Thanks! Landed in b209a6e. |
@seishun is this behavior consistent in v4 and v6? Should this be backported? |
@thealphanerd AFAIK this behavior has been the same since |
Checklist
Affected core subsystem(s)
doc
Description of change
'rename' is confusing, and it's not clear what "they" refers to.
Fixes: #9082