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

Watchers can end up watching entire C:/ drive on windows. #606

Closed
filimon-danopoulos-stratsys opened this issue Dec 15, 2022 · 1 comment · Fixed by #628
Closed

Watchers can end up watching entire C:/ drive on windows. #606

filimon-danopoulos-stratsys opened this issue Dec 15, 2022 · 1 comment · Fixed by #628
Assignees
@aomarks

Comments

@filimon-danopoulos-stratsys
Copy link

In some configurations it is possible for chokidar to end up watching the entire C:/ drive on windows machines. This in turn leads exceptions being thrown due to locked files being read.
See the following reproduction repo https://github.com/filimon-danopoulos-stratsys/wireit-watch-issue for steps to reproduce. Note that the reproduction it is not 100% reliable, sometimes it takes a while for the condition to show.
@aomarks aomarks self-assigned this Jan 3, 2023
@aomarks aomarks mentioned this issue Jan 3, 2023
Merged
aomarks added a commit that referenced this issue Jan 3, 2023
@aomarks
Only register watchers for package-lock.json files that exist at the …
a7f9ca5 
…time of analysis (#628)

### Background

We automatically add `package-lock.json` (or equivalent depending on the package manager) entries to the `files` of every script during analysis. We do this so that updates to dependencies invalidate the fingerprint and trigger re-runs.

However, previously we added all *potential* `package-lock.json` paths to the `files` array, whether or not they exist. Meaning for a script defined in `/foo/bar/package.json` we would add:
  - `/foo/bar/package-lock.json`
  - `/foo/package-lock.json`
  - `/package-lock.json`

This is technically correct, however the effect of this in watch mode is that we would register a chokidar watcher for all of those paths, which meant asking the OS to listen for any new file created in any of those directories (including the root directory).

It seems that on Windows, this will occasionally cause errors such as `EBUSY: resource busy or locked, lstat 'C:\DumpStack.log.tmp`. I'm a bit unclear as to why an `lstat` is being issued for a file in `C:\`, since it doesn't seem necessary to stat files that we aren't actually interested in -- but that is what happens through chokidar for some reason.

### This PR

We now only add `package-lock.json` files to the `files` array to a script if the `package-lock.json` exists at the time of analysis. This does mean that a new watch iteration won't occur if a new `package-lock.json` is created during a watch session, but that's really not very important, and not worth the cost/bugs associated with always watching all parent directory listings for all scripts.

Fixes #606
@aomarks
Copy link
Member

aomarks commented Jan 3, 2023

This should be fixed in 0.9.3, which was just released. Let me know if you still encounter issues!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@aomarks aomarks

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Only register watchers for package-lock.json files that exist google/wireit
2 participants
@aomarks @filimon-danopoulos-stratsys