Error: EPERM, rename '...something...'

[dy]

I use watchify as a npm task in windows, and periodically it stops watching and logs

{ [Error: EPERM, rename 'c:\Users\dmitry\Dropbox\Projects\mod\dist\mod.js']
  errno: 50,
  code: 'EPERM',
  path: 'c:\\Users\\dmitry\\Dropbox\\Projects\\mod\\dist\\mod.js' }

Restarting fixes it for a while utill the next EPERM error.

[highwaycoder]

+1

[plus-]

👍

[divmgl]

Yeah what is this about? I still can't figure it out. Maybe write access has been blocked in these situations?

[terebentina]

To me it happens when I save a file, watchify kicks in then I quickly save again, before watchify finishes rebuilding the first time.
It is very annoying as it means I have to keep watching the watchify task to make sure it still rebuilds every time.

[highwaycoder]

I also get it under those circumstances, which occur more frequently for me
when I'm using WebStorm or have an editor set up to behave like WebStorm
(saving every time I make a change).

On Tue, Oct 14, 2014 at 12:12 PM, Dan Caragea notifications@github.com
wrote:

To me it happens when I save a file, watchify kicks in then I quickly save
again, before watchify finishes rebuilding the first time.
It is very annoying as it means I have to keep watching the watchify task
to make sure it still rebuilds every time.

Reply to this email directly or view it on GitHub
#83 (comment).

[dy]

Yes, I have sublime's always save option enabled, so that's probably the case.

[j201]

+1

[terebentina]

Upon further investigation, using a gulp task with watchify is both faster and doesn't seem to suffer from this problem. For me only watchify from the command line had this problem.

[davepile]

Today I upgraded to watchify 2.1.1
I had previously been getting this EPERM error quite frequently and it did seem that it happened after quickly saving several files, or the same file, in quick succession.

After the upgrade I again got this error and it was definitely not the result of quickly saving files. Below is the error I received and the previous save was some 20 - 30 seconds earlier and resulted in correct output (or at least a notification in the terminal that the output was written correctly, i didnt test the actual bundle.js)
{ [Error: EPERM, rename 'C:\work\projects\cordova\propman\www\js.bundle.js']
errno: 50,
code: 'EPERM',
path: 'C:\work\projects\cordova\propman\www\js.bundle.js' }

Hope this helps

[j201]

I can reproduce it with watchify 2.1.1 by doing the following:

• Create a JS file test.js with a syntax error
• watchify test.js -o test-out.js (Prints a ParseError)
• Remove the syntax error
• Save test.js (no errors yet)
• Save test.js again

This produces the following:

{ [Error: EPERM, rename 'C:\Users\alex\Documents\temp\test-out.js']
  errno: 50,
  code: 'EPERM',
  path: 'C:\\Users\\alex\\Documents\\temp\\test-out.js' }

Now that I can reproduce it, I'll take a look at possible fixes when I get a chance.

[jednano]

@j201 your repro steps give me the same error.

[jednano]

FWIW, I have a Node script I use to remedy the problem in my scenario. Perhaps it might be useful to fix the issue as well as for people to use before it gets fixed:

var browserify = require('browserify');
var fs = require('fs');
var mkdirp = require('mkdirp');
var watchify = require('watchify');

var args = process.argv.slice(2);
var env = args[0];
var shouldWatch = args[1] === '--watch';

var options = (shouldWatch) ? watchify.args : {};

var b = browserify(options);

if (shouldWatch) {
    b = watchify(b);
    b.on('update', rebundle);
}

b.add('./lib/index.js');

var outdir = './dist/';
mkdirp.sync(outdir);
rebundle();

function rebundle() {
    var outpath = outdir + '/index-bundle.js';
    b.bundle().pipe(fs.createWriteStream(outpath));
}

I hope it's helpful to someone.

[manuelcabral]

For some reason this seems to fix it on my system: digisfera@f3f61b4

While there isn't a more permanent fix, you can try this version with npm install digisfera/watchify

[nickcoad]

+1, first reported on 15th Aug 2014 and still no official fix...

[jonathancloudshare]

+1

[EugeneZ]

+1, I had this issue and using the fork @manuelcabral recommended above fixed it.

[rchanou]

+1 This is part of the reason I've been using webpack instead.

[flq]

👎 same here, annoying bug.

[ryan1234]

+1. Trying to fork from @manuelcabral and if that doesn't work, it's webpack time.

[liddellj]

I'm seeing this as well using 2.4.0 on Windows 7 using Sublime.

[Larzans]

+1

PhpStorm, Windows 7, the first time it compiles without problem, but as soon as i change something and the compilation starts, it reports the blocked file.

As long as watchify is running i can't do anything with the file, windows reports ownership as "unable to determine" and doesn't let me do anything with it.

Restarting watchify makes it compile once, but as soon as i chang sth. it is the same all over again, rendering watchify virtually useless.

It started happening yesterday, after investigating a while i couldn't make out any change i made to the system other that adding and including a new file to my project, very strange indeed...

fix by @manuelcabral didn't work unfortunately

my gulpfile:

...
gulp.task('clean', function () {
    return gulp.src(paths.dist)
    .pipe(vinylPaths(del))
    .on('error', gutil.log);
});

gulp.task('copy', ['clean'], function () {
  gulp.src(paths.assets)
    .pipe(gulp.dest(paths.dist + 'assets'))
    .on('error', gutil.log);
});

gulp.task('copylibs', ['clean'], function () {
  gulp.src(paths.libs)
    .pipe(gulpif(!watching, uglify({outSourceMaps: false})))
    .pipe(gulp.dest(paths.dist + 'js/lib'))
    .on('error', gutil.log);
});

gulp.task('compile', ['clean'], function () {
  var bundler = browserify({
    cache: {}, packageCache: {}, fullPaths: true,
    entries: [paths.entry],
    debug: watching
  });

  var bundlee = function() {
    return bundler
      .bundle()
      .pipe(source('main.min.js'))
      .pipe(jshint('.jshintrc'))
      .pipe(jshint.reporter('default'))
      .pipe(gulpif(!watching, streamify(uglify({outSourceMaps: false}))))
      .pipe(gulp.dest(paths.dist))
      .on('error', gutil.log);
  };

  if (watching) {
    bundler = watchify(bundler);
    bundler.on('update', bundlee)
  }

  return bundlee();
});
gulp.task('default', ['connect', 'watch', 'build']);
gulp.task('build', ['clean', 'copy', 'copylibs', 'compile']);

Then after first compile when changing sth. and watchify kicks in:

...
[13:41:35] Starting 'compile'...
[13:41:35] { [Error: EPERM, open 'H:\Webpages\dist\main.min.js']
  errno: 50,
  code: 'EPERM',
  path: 'H:\\Webpages\\dist\\main.min.js' }
[13:41:35] 'compile' errored after 178 ms
[13:41:35] Error: EPERM, open 'H:\Webpages\dist\main.min.js'
[13:41:35] { [Error: EPERM, open 'H:\Webpages\dist\main.min.js']
  errno: 50,
  code: 'EPERM',
  path: 'H:\\Webpages\\dist\\main.min.js' }

[Larzans]

As i mentioned before, the error occurred every time i changed a file and watchify kicked in, i didn't install or updated anything previous to the first time the error occurred, i simply added more code (via an extra module).

Removing some modules and therefore reducing the compile / clean time let the problem disappear, so it seems to be related to the time the different tasks need.

In my case, every time my clean task took more than x ms, i would get the EPERM message.

gulp.task('clean', function () {
    return gulp.src( './dist/' )
    .pipe(vinylPaths(del))
    .on('error', gutil.log);
});

I don't know why that is, but this seems to be the trigger (tested with various complexities of my program).

Maybe somebody better versed in gulp can figure this one out.

[ArtskydJ]

Anyone who is interested (@liddellj, @ryan1234, @flq) can test #165 (which fixed the EPERM problem on my machine) and give feedback. Thanks!

[Larzans]

cmd.js not cli.js ;)

[ArtskydJ]

Thanks, fixed.

[zertosh]

I think I've got a fix for this in #169 - think because I've only tested it in a Win7 VM. Can a few of you give it a test drive and comment on the PR? I'd like to merge this fix in fast so I can get these other goodies out #168

[zertosh]

The fix was published as watchify@2.6.2

[davepile]

watchify@2.6.2 on win 8.1 looks good!

Just tested saving a file with an error then correcting the error and resaving several times. No problems.
Nice work, thanks.

[flq]

Just had an extensive session on a Windows10 Preview VM, no problems. Definitely a much nicer experience, thanks for the work!

[michaeljonathanblack]

I am seeing this issue as long as the folder the file is contained in is open in Sublime Text 3. I'm not certain if this is an issue with the editor, watchify or something else, unfortunately.

[michaeljonathanblack]

This issue only exists in Windows (reproduced on Windows 7); on Ubuntu I do not encounter the same permissions issues. This also cannot be reproduced with Sublime Text 2, so I'll be redirecting my ire toward ST3.