gulp-watch + WebStorm fails with Error: ENOENT: no such file or directory, stat '...\bootstrap.spec.js___jb_tmp___'

[alexander-ossur]

Hi there,

This is also related to: ckeditor/ckeditor5#154, t.e. WebStorm creates a temporary file before saving, and then instantly deletes (i guess) after that. But |gulp-warch| still is about to read this, and possibly without an |exists| check or |try..catch|.

gulp_watch (["./**/test-suite/ *"], { ignoreInitial: true })
.pipe (gulp.dest ("another destination"))

[06:15:34] Using gulpfile c:\Workspace\market\gulpfile.js
[06:15:34] Starting 'watch-chrome-extension-with-tests'...
events.js:160
throw er; // Unhandled 'error' event
^

Error: ENOENT: no such file or directory, stat 'C:\Workspace\market\src\client\browser\extension\chrome\1.0.0\src\test-suite\bootstrap.spec.js___jb_tmp___'
at Error (native)

Process finished with exit code 1

[UltCombo]

This is due to the "atomic save" feature. It is the same issue as #238, just with a different editor and file extension.

Basically, atomic saving works by writing the all the file contents to a temporary file, then replaces the original file with the temporary one. This is supposed to help preventing corrupting files (e.g. power shortage in the the middle of saving a file, HD crash etc.), in which case you'd still have the old version of the file instead of an incomplete version. But it also leads to issues with phantom files being reported by file system watchers.

In any case, you would never want these files to be detected by the watcher nor processed by gulp, so you can either add an ignore pattern (that is, add !**/*___jb_tmp___ to your globbing patterns array) or disable your editor/IDE's atomic saving feature.

---

It's on my map to improve our error handling in this case, but I haven't got to it yet. I can tell a few things from just a quick glance:

• A mere fs.access/fs.exists check won't solve the issue. It is susceptible to race conditions: the file may exist when the check is run, but may no longer exist when trying to read it. Also, the file may be deleted while we are reading it (which is likely the problem here).
• The error seems to be emitted from a stream (likely vinyl-fs), so a try/catch would never catch it.

Take this quick diagnosis as just pointers in case anyone has got time to contribute and improve our error handling regarding files that are deleted right after being added/changed (not necessarily atomic save artifacts).

As for issues related to atomic save artifacts, such as this one and #238, you don't want gulp to process these temporary files so please add an ignore pattern or disable atomic saving, as I've mentioned earlier.

Closing this as we are already tracking this case's error handling in #238.