Sometimes when I'm running Gulp, there will spontaneously be an issue with a directory I've cleaned and Gulp suddenly can't access it. If I look into it, I find that the folder has lost its owner and Windows says "Unable to display current owner" in the folder's properties -> Security -> Advanced. From here it's nearly impossible to get rid of. I have to execute a takeown using the administrator account through CMD ran as administrator, and even that didn't really work the last time, so I restarted and the folder was gone.
I realize that's an incredibly unscientific rundown and doesn't help to narrow down the issue, but you can find my gulpfile here, as perhaps something sticks out as unusual. The build folder is the one that's getting borked. Most recently, the issue happened during the imagemin task run as part of the build task, but this isn't consistent.
This rarely happens (and I'm sure I couldn't recreate it if I tried), so I know I'm kind of shooting in the dark. Maybe something in my tasks is unusual?
This would most likely happen when you try to write to your build directory while cleaning it but almost all your tasks signal completion correctly (except css-to-sass) and you are using run-sequence so I'm not sure. Maybe just try fixing that one task?
Can you elaborate some? What do you mean by signal completion correctly?
To follow up, I removed the css-to-scss task entirely from both the default and build tasks, and the error still occurs. I can replicate it fairly consistently on at least one project by running the default task, saving a file that triggers the watch task (specifically triggering the styles task), quitting watch and then trying to run gulp build, which results in Error: EPERM, mkdir 'path\to\build\img'.
Managed to distill it some:
Here is the gulp build task I'm running on Windows 10 in the Bash command line:
// Build Task
gulp.task('build', function(cb) {
runSequence('clean', 'clear-cache', 'build-images', cb);
});
And its subtasks:
gulp.task('clean', function(cb) {
del(['build'], cb);
});
gulp.task('clear-cache', function() {
cache.clearAll();
});
gulp.task('build-images', function() {
return gulp.src(paths.images)
.pipe(plumber())
.pipe(imagemin({
progressive: true,
interlaced: true
}))
.pipe(gulp.dest(destPaths.images))
.pipe(notify('Image optimized!'));
});
All the plugins being used are the latest versions, and here are their definitions:
var gulp = require('gulp');
var cache = require('gulp-cache');
var del = require('del');
var imagemin = require('gulp-imagemin');
var notify = require('gulp-notify');
var plumber = require('gulp-plumber');
var runSequence = require('run-sequence');
Here are the paths and destPaths variables being referenced:
// Define our paths
var paths = {
...
images: 'img/**/*.{png,jpg,jpeg,gif,svg}'
};
var destPaths = {
...
images: 'build/img'
};
If I run gulp build twice in succession, I pretty consistently get:
[09:27:04] Using gulpfile q:\wamp\...\gulpfile.js
[09:27:04] Starting 'build'...
[09:27:04] Starting 'clean'...
[09:27:04] Finished 'clean' after 4.75 ms
[09:27:04] Starting 'clear-cache'...
[09:27:04] Finished 'clear-cache' after 4.7 ms
[09:27:04] Starting 'build-images'...
[09:27:04] Plumber found unhandled error:
Error: EPERM, mkdir 'q:\wamp\...\build\img'
[09:27:04] gulp-imagemin: Minified 2 images (saved 532 B - 41.7%)
[09:27:04] Plumber found unhandled error:
Error: EPERM, mkdir 'q:\wamp\...\build\img'
With ... being my file path. At this point, if I look into it, I find that the build folder has lost its owner and Windows says "Unable to display current owner" in the folder's properties -> Security -> Advanced. From here it's nearly impossible to get rid of (can't delete, rename, etc), but if I restart the computer, the build directory as a whole disappears and I'm good to go.
If this looks like it may rather be a gulp-imagemin bug than gulp as a whole, I can move the issue there, as well.
Thanks ahead for any advice.
For what it's worth, I had a very similar issue which I eventually tracked down to Sublime Text 3 (running on Windows 10 and NTFS). I excluded the build folder from from the project, so that it isn't displayed in the folder sidebar. This was enough to avoid EPERM errors. The strange thing was that del/rimraf clearly thought it had deleted the files, but listing the content of the directory afterwards showed the stray file still there, and writing to it failed since it's in some strange state.
Yeah, guess I could follow up here: may be a thing with Atom as well. If it's open in there, it's claiming ownership it seems, preventing me from doing anything with it.
I'll probably add that our CI system occasionally throws this error. Our build agents all share an NPM cache which is likely the root however it occurs even when only one agent is building and hence none of the files should be touched by any other process.
I'm getting a similar error when trying to copy files/directories to a network drive, though the error is caused by a chmod in this case:
[17:25:27] Error: EPERM: operation not permitted, chmod 's:\lwebwww\lweb802debug\css'
at Error (native)
I'm not sure there's anything we can do about other processes claiming ownership of files; however, in going over some code for gulp 4, I found that vinyl-fs wasn't using graceful-fs when creating directories and we had some chmod/utimes problems that we've since fixed. If you are using gulp 3, I suggest upgrading to gulp 4 and see if that helps.
Most helpful comment
Yeah, guess I could follow up here: may be a thing with Atom as well. If it's open in there, it's claiming ownership it seems, preventing me from doing anything with it.