error "ENOENT on dotfile" started happening in 0.8.2

[mreinstein]

I'm getting ENOENT errors when changing watched files.

{ [Error: ENOENT, rename 'assets/javascripts/.wrapp.js']
  errno: 34,
  code: 'ENOENT',
  path: 'assets/javascripts/.wrapp.js' }

[ustun]

Same here, restarting watchify fixes it.

[nibblebot]

+1 on this. restart does not fix anything for me.
i'm also seeing multiple log output for singular file change occasionaly..

0.10.5 node
4.1.5 browserify
0.10.1 watchify
linux host

# initial run
1301 bytes written to public/build/bundle-app.js (0.19 seconds)
# file changed
1279 bytes written to public/build/bundle-app.js (0.22 seconds)
{ [Error: ENOENT, rename 'public/build/.bundle-app.js']
  errno: 34,
  code: 'ENOENT',
  path: 'public/build/.bundle-app.js' }
{ [Error: ENOENT, rename 'public/build/.bundle-app.js']
  errno: 34,
  code: 'ENOENT',
  path: 'public/build/.bundle-app.js' }
# file changed; two log outputs...
1301 bytes written to public/build/bundle-app.js (0.06 seconds)
1301 bytes written to public/build/bundle-app.js (0.05 seconds)
{ [Error: ENOENT, rename 'public/build/.bundle-app.js']
  errno: 34,
  code: 'ENOENT',
  path: 'public/build/.bundle-app.js' }

I also tried using the --delay 1000 undocumented option to see if I could reduce race condition, but I saw no real change.

[nibblebot]

@mreinstein can you update the issue title to reflect the issue. something like "ENOENT on dotfile" or similar

[clehner]

I was seeing this issue as well and then realized it was because there was an old watchify process still running, which had somehow detached from the terminal's job control and seemed to be causing a race condition, trying to build the same bundle file. So I killed that process and then things worked fine.

[nibblebot]

@clehner This is a likely explanation for my bug as I was indeed background watchify in a parent process with intent to kill it later (at end of parent process) and ended up with some stray children watchify processes. Haven't seen this issue since I killed the surviving background processes.

[joeellis]

Found this when searching for this bug, and I too had a background process still running that I wasn't aware of. Killed the process, bug went away. I think this issue can probably be closed since that solution seems to work well.

[pluma]

+1

This is still happening for me with the current version of watchify. I'm guessing this has something to do with multiple files being modified in rapid succession (i.e. faster than watchify can update the bundle). This seems to happen eventually even when there are no other node/watchify processes around when I start watchify (and I don't manually start new ones).

[ivan-kleshnin]

+1

[gasi]

+1

[rodryquintero]

+1

[zertosh]

This is the same issue as #83. I'm tracking it there. I've got a fix in #169. I would really appreciate it if someone test drove it and reported their node and OS version in the PR comments.