ungit icon indicating copy to clipboard operation
ungit copied to clipboard

ungit crashes with rapid file system modification

Open campbellcole opened this issue 2 years ago • 5 comments

(This problem has only come up for me with Rust projects, due to the nature of the build procedure)

To reproduce easily:

  • create an empty Cargo project: cargo new ungit_poc
  • in a new shell, run ungit in that folder: cd ungit_poc && ungit
  • in the first shell, run cargo: cargo check or cargo build

Ungit crashes with an error similar to:

Error: ENOENT: no such file or directory, watch '<project_dir>/target/debug/deps/rmetaY6KMh5'

This happens because the target directory is extremely volatile during compilation/checking, and ungit doesn't seem to be written in such a way that handles extremely rapid filesystem mutation.

There are two ways to fix this:

  1. Ensure Ungit does not attempt to watch files in .gitignore/.ignore
  2. Change how FSWatcher is being used so that rapid changes won't cause this race condition

campbellcole avatar Jul 12 '22 22:07 campbellcole

Nodegit uses node-watch which does filter ignored dirs, so either that isn't working or you have an old version?

The race itself is interesting, why would it stat the file? Maybe it's a bug in node-watcher, trying to determine what the change is?

A full stack dump would be useful. Also, try to repro in bash with touch and rm.

wmertens avatar Jul 13 '22 06:07 wmertens

Would be nice to get a stacktrace for this. Might be related to https://github.com/yuanchuan/node-watch/issues/108

campersau avatar Jul 13 '22 13:07 campersau

Ungit version 1.5.20+9ced7530

Stacktrace:

2022-07-14T00:03:15.220Z - error: Error: ENOENT: no such file or directory, watch '/home/campbell/Programming/[removed]/target/debug/deps/rmetawQil0f'
    at FSWatcher.<computed> (node:internal/fs/watchers:244:19)
    at Object.watch (node:fs:2264:34)
    at /home/campbell/.nvm/versions/node/v16.15.1/lib/node_modules/ungit/node_modules/node-watch/lib/watch.js:398:22
    at hasNativeRecursive (/home/campbell/.nvm/versions/node/v16.15.1/lib/node_modules/ungit/node_modules/node-watch/lib/has-native-recursive.js:61:12)
    at Watcher.watchDirectory (/home/campbell/.nvm/versions/node/v16.15.1/lib/node_modules/ungit/node_modules/node-watch/lib/watch.js:381:3)
    at /home/campbell/.nvm/versions/node/v16.15.1/lib/node_modules/ungit/node_modules/node-watch/lib/watch.js:305:20
    at hasNativeRecursive (/home/campbell/.nvm/versions/node/v16.15.1/lib/node_modules/ungit/node_modules/node-watch/lib/has-native-recursive.js:61:12)
    at FSWatcher.internalOnChange (/home/campbell/.nvm/versions/node/v16.15.1/lib/node_modules/ungit/node_modules/node-watch/lib/watch.js:291:7)
    at FSWatcher.emit (node:events:527:28)
    at FSEvent.FSWatcher._handle.onchange (node:internal/fs/watchers:212:12)
Stopped keeping ungit alive

Can't seem to reproduce this using touch and rm (or mkdir and rm -rf), I think cargo just works too much faster than those commands. The presence of onchange makes me think that the file is created and destroyed before FSWatcher has finished its initial stat of the file.

campbellcole avatar Jul 14 '22 00:07 campbellcole

right, this seems like a bug with node-watch, where it tries to watch newly created folders but they're already removed by the time it gets to it.

Mostl likely the bug is here https://github.com/yuanchuan/node-watch/blob/5743e51a861bfe3d372a99dd388626b324905065/lib/watch.js#L302-L317

@campbellcole would you mind opening an issue on node-watch?

wmertens avatar Jul 17 '22 20:07 wmertens

@wmertens will do. Thanks for your time 😃

campbellcole avatar Jul 17 '22 20:07 campbellcole