Skip to content
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.

Sign up for GitHub

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

Jump to bottom

fs: migrate fs_event_wrap to internal/errors #17851

Closed
wants to merge 1 commit into from
Closed

fs: migrate fs_event_wrap to internal/errors #17851

wants to merge 1 commit into from

Conversation

maclover7
Copy link
Contributor

@maclover7 maclover7 commented Dec 24, 2017 •
edited
Loading

Migrates fs_event_wrap.cc to internal/errors style.

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

fs

@maclover7 maclover7 added the fs Issues and PRs related to the fs subsystem / file system. label Dec 24, 2017
@nodejs-github-bot nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. fs Issues and PRs related to the fs subsystem / file system. labels Dec 24, 2017
@maclover7
Copy link
Contributor Author

ping @TimothyGu

@joyeecheung joyeecheung mentioned this pull request Jan 15, 2018
Closed
2 tasks
@targos
Copy link
Member

targos commented Jan 15, 2018

@maclover7 #17682 landed. Can you please rebase?

@maclover7 maclover7 force-pushed the jm-fsevent-error branch 2 times, most recently from 66bb103 to c28b53a Compare January 20, 2018 18:35
@maclover7
Copy link
Contributor Author

updated @targos

@maclover7
Copy link
Contributor Author

CI: https://ci.nodejs.org/job/node-test-pull-request/12646/

@targos targos added the semver-major PRs that contain breaking changes and should be released in the next major version. label Jan 20, 2018
@targos targos requested a review from a team January 21, 2018 10:52
mcollina
mcollina reviewed Jan 22, 2018
View reviewed changes
test/parallel/test-fs-watch.js Outdated
@@ -64,7 +64,7 @@ for (const testCase of cases) {
assert.strictEqual(eventType, 'change');
assert.strictEqual(argFilename, testCase.fileName);

watcher.start(); // should not crash
watcher.start('should not crash'); // should not crash
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is not the same, why this change?
It seems we are not exposing start  at all, see https://nodejs.org/api/fs.html#fs_class_fs_fswatcher.
I think we should add it to the docs.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this should be watcher.start(testCase[testCase.field])?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at #17430 and #17432 I think this line should be either:

  1. watcher.start(testCase[testCase.field]), we enforce that a filename must be passed to .start()
  2. watcher.start(), and return silently in FSWatcher.prototype.start() if the filename is undefined (current behavior).

Copy link
Member

@joyeecheung joyeecheung Jan 23, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Umm, looking more closely I think .start() is accepted the second time it is called (i.e. the wrap is already initialized to watch on a file), so in JS land we should check if the wrap is initialized before calling validatePath(). The easiest way to do it is to store a field in the FSWatcher.prototype.start() in JS land, echoing what's being done in the C++ land (it also needs to be updated in .close())

Copy link
Member

@joyeecheung joyeecheung Jan 23, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or, if we don't want to return silently when someone tries to call .start() again on the initialized watcher:

if (!isInitialized) {
  validatePath(filename);
} else {
  throw errors.Error('ERR_FS_EVENT_STARTED');  // A new Error indicating this has been started.
}

If we don't even want to document .start(), we can just assert(isInitialized) instead of creating a public error for it.

mhdawson
mhdawson approved these changes Jan 31, 2018
View reviewed changes
Copy link
Member

@mhdawson mhdawson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM once comment about watcher.start() is addressed.

@maclover7
Copy link
Contributor Author

maclover7 commented Feb 4, 2018 •
edited
Loading

updated @joyeecheung PTAL

joyeecheung
joyeecheung approved these changes Feb 5, 2018
View reviewed changes
Copy link
Member

@joyeecheung joyeecheung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with an suggestion

lib/fs.js
@@ -1664,6 +1664,8 @@ fs.appendFileSync = function(path, data, options) {
function FSWatcher() {
EventEmitter.call(this);

this._initialized = false;
Copy link
Member

@joyeecheung joyeecheung Feb 5, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a comment here mentioning that this should be kept in sync with the initialized field of the C++ wrap? (Arguably better if this is an accessor property on the prototype of FSWatcher, that way there is no need to set this field in start and close, although that brings a few more calls into C++ so I am fine with this as well)

@joyeecheung
Copy link
Member

CI: https://ci.nodejs.org/job/node-test-pull-request/12941/

@BridgeAR BridgeAR added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Feb 7, 2018
@BridgeAR
Copy link
Member

@maclover7 would you be so kind and rebase and also address the comment?

@BridgeAR BridgeAR removed the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Feb 10, 2018
@BridgeAR
Copy link
Member

Ping @maclover7

@joyeecheung joyeecheung mentioned this pull request Feb 27, 2018
Closed
3 tasks
@BridgeAR
Copy link
Member

BridgeAR commented Mar 2, 2018

Closing due to no further progress. @maclover7 please feel free to reopen in case you would like to continue working on this.

@BridgeAR BridgeAR closed this Mar 2, 2018
@joyeecheung joyeecheung mentioned this pull request Mar 2, 2018
Closed
3 tasks
@maclover7 maclover7 deleted the jm-fsevent-error branch July 22, 2018 13:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@mcollina mcollina mcollina left review comments

@mhdawson mhdawson mhdawson approved these changes

@BridgeAR BridgeAR BridgeAR approved these changes

@joyeecheung joyeecheung joyeecheung approved these changes

@targos targos targos approved these changes

@jasnell jasnell jasnell approved these changes

@TimothyGu TimothyGu Awaiting requested review from TimothyGu

Assignees
No one assigned
Labels
c++ Issues and PRs that require attention from people who are familiar with C++. fs Issues and PRs related to the fs subsystem / file system. semver-major PRs that contain breaking changes and should be released in the next major version.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
8 participants
@maclover7 @targos @joyeecheung @BridgeAR @mcollina @jasnell @mhdawson @nodejs-github-bot