Error ENOTEMPTY when deleting a directory recursively. about shelljs

[arturadib]

Hi Rubens, can you please zip/archive the contents of the directory that's causing you trouble and send it to me? (my email is on my Github profile page)

Also, can you please paste here the output of the command /bin/ls -laR in that directory?

Thanks!

[rmariuzzo]

Email sent with zipped dir. I cannot /bin/ls -laR because is a Windows Server.

[mstade]

I see this happening on windows as well. It happens a lot in git bash or cmd as well, and usually when I try the same command again it works. Does it happen if you retry the shelljs command? I'd be surprised if this is anything but Windows being Windows.

[rmariuzzo]

It is just as you said. When it happens then just retrying it Windows-magically works.

[XhmikosR]

From my experience this happens when the directory I'm trying to remove is used by another process, e.g. python running a webserver from that directory.

[mstade]

In those situations you get an EPERM error, if I recall correctly.

[XhmikosR]

Actually I get rm: could not remove directory (code EBUSY) so irrelevant to this issue. :)

[mstade]

Interesting though, we usually get EPERM I believe, which was confusing as hell at first when you had some process in the background somewhere. Usually running process explorer will let you figure out which process it is to kill it, but it's massively annoying. It could be something silly such as windows explorer having that folder open, or some app that you used to browse that folder three hours ago and it's still locking it. Windows is messy :(

[arturadib]

Guys I'm unable to play with this issue on Windows atm. Would love if someone would lend a hand with this issue :)

[rmariuzzo]

You can't reproduce this issue?

[arturadib]

@rmariuzzo I don't have a Windows box atm

[sparkleholic]

I also facing the same issue. It seems to be causing occasionally on windows.

[andreialecu]

+1 Seem to be getting the same error here on Windows occasionally. It's annoying becuase I'm running a pretty big test suite and the tests randomly fail because of this and I need to restart it every time until it eventually works.

[andreialecu]

I have changed the code block at https://github.com/arturadib/shelljs/blob/master/src/rm.js#L49 with this:

  var result, files;
  try {
    files = fs.readdirSync(dir);
    result = fs.rmdirSync(dir);
  } catch(e) {
    common.error('could not remove directory (code '+e.code+'): ' + dir, true);
    if (e.code == "ENOTEMPTY") {
      common.error('files found: ' + files.join(', '));
    }

And I can indeed see that there are some files left behind sometimes, randomly.

EDIT: After some more digging, this may be related to:
nodejs/node-v0.x-archive#7164
nodejs/node-v0.x-archive#3051

However, the files should be properly closed, but this is in a rapid succession of unit tests with directories being created, files written, read, then deleted by various means, both async and sync. All fingers point to a nodejs bug of some sort.

[andreialecu]

I think the only way to fix this on Windows is to auto-retry. I have found a library that doing exactly this here:
https://github.com/isaacs/rimraf

[andreialecu]

I made a pull request for this that auto-retries for up to 1 second on Windows. See #179. This has made it finally usable for my purposes, fixing all errors I was getting.

[nfischer]

Closing this since #179 is merged. Please reopen if this error persists

[dpmott]

For me, shx version 0.3.2 exhibits this same intermittent behavior when run from an npm script from within VSCode; when it fails, it fails immediately (no waiting for up to 1 second). It would appear that the changes from #179 may have been lost.

[nfischer]

I still see the changes:

shelljs/src/rm.js

Lines 53 to 78 in 4e38240

	try {
	// Retry on windows, sometimes it takes a little time before all the files in the directory are gone
	var start = Date.now();
	// TODO: replace this with a finite loop
	for (;;) {
	try {
	result = fs.rmdirSync(dir);
	if (fs.existsSync(dir)) throw { code: 'EAGAIN' };
	break;
	} catch (er) {
	/* istanbul ignore next */
	// In addition to error codes, also check if the directory still exists and loop again if true
	if (process.platform === 'win32' && (er.code === 'ENOTEMPTY' || er.code === 'EBUSY' || er.code === 'EPERM' || er.code === 'EAGAIN')) {
	if (Date.now() - start > 1000) throw er;
	} else if (er.code === 'ENOENT') {
	// Directory did not exist, deletion was successful
	break;
	} else {
	throw er;
	}
	}
	}
	} catch (e) {
	common.error('could not remove directory (code ' + e.code + '): ' + dir, { continue: true });
	}

I don't know enough about this problem to know if the bug still exists though.