Doesn't work #25

Petah · 2013-07-09T03:31:18Z

fs.js:456
  return binding.rmdir(pathModule._makeLong(path));
                 ^
Error: ENOTEMPTY, directory not empty 'c:\work\modules\raptor-gold\build\temp'
    at Object.fs.rmdirSync (fs.js:456:18)
    at Function.rimrafSync [as sync] (c:\work\modules\raptor-gold\node_modules\rimraf\rimraf.js:128:12)
    at Object.build (c:\work\modules\raptor-gold\build\raptor-builder.js:77:12)
    at Object.<anonymous> (c:\work\modules\raptor-gold\build\build.js:5:9)
    at Module._compile (module.js:449:26)
    at Object.Module._extensions..js (module.js:467:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.runMain (module.js:492:10)
    at process.startup.processNextTick.process._tickCallback (node.js:244:9)

The text was updated successfully, but these errors were encountered:

isaacs · 2013-07-11T23:12:07Z

Can you provide more details? There's something in there that it's failing to delete. What files are in there? How are you creating this dir?

Petah · 2013-07-11T23:59:02Z

Seems that it was creating files while rimraf was trying to delete at the same time

mlarcher · 2013-11-08T10:42:12Z

@isaacs: could you please check out the log pasted in the phantomjs ticket and tell me if you need more info in order to investigate this issue ?

isaacs · 2013-11-08T15:48:49Z

If you're creating files while trying to rimraf the dir, then yes, that will definitely not work. That will also confuse the builtin rm -rf command line utility. Don't do that!

isaacs · 2013-11-08T15:51:18Z

@mlarcher What's happening in the phantomjs ticket's npm log looks like the phantomjs install script fails (exits non-zero), but is still doing stuff (perhaps because it shelled out to windows unzip, which does not stop writing files immediately when the process exit event happens.)

Do not fetch stuff at install time. Fetch it when you need it.

The correct behavior in this case is for rimraf to surface the error. Rimraf is not, and cannot ever be, an atomic FS operation.

Petah · 2013-11-09T01:57:05Z

While I agree that rimraf should not work in this case maybe a more meaningful error would be beneficial.

nullivex · 2013-11-10T05:26:42Z

In case other people are having this issue its most likely a virus scanner scanning the folder where the file operations are happening. This will make the files in use during the deletion.

In this specific case it was caused by ESET Anti-Virus.

SOLUTION: Ignore the following paths

Make sure to replace the username with yours obviously. I have a feeling this is why the issue is so intermittent for most people and unconfirmed.

This should also help fix Medium/phantomjs#108

isaacs · 2013-11-10T18:18:05Z

What error code gets raised with the anti-virus program thwarts rimraf? There's some special handling for EBUSY for exactly that purpose.

nullivex · 2013-11-10T18:27:08Z

This is the error code that gets thrown while the anti-virus is scanning the files in the directory. I assume what is happening here is that the phantomjs install is trying to remove the directory while the Anti-Virus still has file descriptors open in the folder. Not sure how you would formulate a workaround for that? Maybe some sort of blocking?

Errorlog:
Phantom installation failed { [Error: ENOTEMPTY, directory not empty 'C:\tmp\phantomjs\phantomjs-1.9.2-windows.zip-extract-1380823312359\phantomjs-1.9.2-windows']
errno: 53,
code: 'ENOTEMPTY',
path: 'C:\tmp\phantomjs\phantomjs-1.9.2-windows.zip-extract-1380823312359\phantomjs-1.9.2-windows',
syscall: 'rmdir' } Error: ENOTEMPTY, directory not empty 'C:\tmp\phantomjs\phantomjs-1.9.2-windows.zip-extract-1380823312359\phantomjs-1.9.2-windows'
at Object.fs.rmdirSync (fs.js:456:18)
at rimrafSync (C:\homedir\Agora\node_modules\phantomjs\node_modules\rimraf\rimraf.js:160:6)
at C:\homedir\Agora\node_modules\phantomjs\node_modules\rimraf\rimraf.js:158:5
at Array.forEach (native)
at rimrafSync (C:\homedir\Agora\node_modules\phantomjs\node_modules\rimraf\rimraf.js:157:21)
at Promise.successFn (C:\homedir\Agora\nodemodules\phantomjs\install.js:291:12)
at Promise.withInput (C:\homedir\Agora\nodemodules\phantomjs\node_modules\kew\kew.js:204:25)
at Promise.resolve (C:\homedir\Agora\node_modules\phantomjs\node_modules\kew\kew.js:92:25)
at resolver (C:\homedir\Agora\node_modules\phantomjs\node_modules\kew\kew.js:264:17)
at cb (C:\homedir\Agora\node_modules\phantomjs\node_modules\ncp\lib\ncp.js:217:38)
npm ERR! phantomjs@1.9.2-2 install: node install.js
npm ERR! cmd "/c" "node install.js" failed with 1
npm ERR!
npm ERR! Failed at the phantomjs@1.9.2-2 install script.
npm ERR! This is most likely a problem with the phantomjs package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! node install.js
npm ERR! You can get their info via:
npm ERR! npm owner ls phantomjs
npm ERR! There is likely additional logging output above.

npm ERR! System Windows_NT 5.1.2600
npm ERR! command "C:\Programme\nodejs\\node.exe" "C:\Programme\nodejs\node_modules\npm\bin\npm-cli.js" "install" "phantomjs"
npm ERR! cwd C:\homedir\Agora
npm ERR! node -v v0.8.9
npm ERR! npm -v 1.1.61
npm ERR! code ELIFECYCLE
npm ERR!
npm ERR! Additional logging details can be found in:
npm ERR! C:\homedir\Agora\npm-debug.log
npm ERR! not ok code 0

isaacs · 2013-11-10T18:35:26Z

ENOTEMPTY would happen when rmdir'ing the directory. That would indicate that either:

A file unlink failed.
A file was written into the directory after doing the readdir step.

In the first case, it would fail with the unlink error, so it's not that.

If the directory was locked (because, as you suggest, a file descriptor was open) then we'd get an EBUSY error, and rimraf would try 3 more times with increasingly slower backoff.

If it IS an EBUSY error, then node isn't exposing it properly, and that's a bug in Node. I notice that you are using a very old version of Node and npm. Please update to v0.10 (or at least, the latest v0.8) and see if that helps the situation.

If there is some other process writing to the dir while we're trying to delete it, then that is a valid error, and rimraf is doing the correct thing by failing in this way.

nullivex · 2013-11-10T18:43:41Z

@isaacs

Actually I just grabbed that trace off the other thread. I can try to get this error reproducible we just got around it by doing this last night. So I figured it might help some of the other people that have been having the issue intermittently.

I was going to note that this feels a lot like a race condition which may be why we are not seeing the right error codes. However I have not had a look at any of the underlying code so I am unsure how the process works.

I should mention that when I got the error I am on the latest version of node 0.10.21, I just didnt have a stack trace handy to show you.

isaacs · 2013-11-10T19:01:43Z

It seems like this error only happens in connection to PhantomJS, is that correct?

I'd look through their build script, and see if it's trying to write to directors it shouldn't, or continuing to do things after exiting with a non-zero status.

nullivex · 2013-11-10T19:03:02Z

I dont believe so I have followed a couple other threads into this one not all related to phantom. I am currently spinning up a VM to make this reproduce-able.

The references above for say grunt-contrib-clean seems to be running into it as well with the same intermittent symptoms so I believe they're related.

nullivex · 2013-11-10T20:46:42Z

@isaacs Okay, got this in a nice reproducible environment.

Setup

Windows 7 64-bit
NodeJS v0.10.21 32-bit
Python 2.7.5 32-bit
Visual Studio Express 2012 32-bit
Git 32-bit latest
ESET 7 64-bit

Instructions

Open command prompt
Type npm -g install karma

Output


> phantomjs@1.9.2-2 install C:\Users\Tandy7\AppData\Roaming\npm\node_modules\kar
ma-phantomjs-launcher\node_modules\phantomjs
> node install.js

Downloading http://phantomjs.googlecode.com/files/phantomjs-1.9.2-windows.zip
Saving to \tmp\phantomjs\phantomjs-1.9.2-windows.zip
Receiving...
Received 782K...
Received 1569K...
Received 2354K...
Received 3136K...
Received 3922K...
Received 4705K...
Received 5495K...
Received 6280K...
Received 6937K total.
Extracting zip contents
Renaming extracted folder \tmp\phantomjs\phantomjs-1.9.2-windows.zip-extract-138
4116124440\phantomjs-1.9.2-windows -> C:\Users\Tandy7\AppData\Roaming\npm\node_m
odules\karma-phantomjs-launcher\node_modules\phantomjs\lib\phantom
Phantom installation failed { [Error: ENOTEMPTY, directory not empty 'C:\tmp\pha
ntomjs\phantomjs-1.9.2-windows.zip-extract-1384116124440\phantomjs-1.9.2-windows
']
  errno: 53,
  code: 'ENOTEMPTY',
  path: 'C:\\tmp\\phantomjs\\phantomjs-1.9.2-windows.zip-extract-1384116124440\\
phantomjs-1.9.2-windows',
  syscall: 'rmdir' } Error: ENOTEMPTY, directory not empty 'C:\tmp\phantomjs\pha
ntomjs-1.9.2-windows.zip-extract-1384116124440\phantomjs-1.9.2-windows'
    at Object.fs.rmdirSync (fs.js:612:18)
    at rimrafSync (C:\Users\Tandy7\AppData\Roaming\npm\node_modules\karma-phanto
mjs-launcher\node_modules\phantomjs\node_modules\rimraf\rimraf.js:160:6)
    at C:\Users\Tandy7\AppData\Roaming\npm\node_modules\karma-phantomjs-launcher
\node_modules\phantomjs\node_modules\rimraf\rimraf.js:158:5
    at Array.forEach (native)
    at rimrafSync (C:\Users\Tandy7\AppData\Roaming\npm\node_modules\karma-phanto
mjs-launcher\node_modules\phantomjs\node_modules\rimraf\rimraf.js:157:21)
    at Promise._successFn (C:\Users\Tandy7\AppData\Roaming\npm\node_modules\karm
a-phantomjs-launcher\node_modules\phantomjs\install.js:291:12)
    at Promise._withInput (C:\Users\Tandy7\AppData\Roaming\npm\node_modules\karm
a-phantomjs-launcher\node_modules\phantomjs\node_modules\kew\kew.js:204:25)
    at Promise.resolve (C:\Users\Tandy7\AppData\Roaming\npm\node_modules\karma-p
hantomjs-launcher\node_modules\phantomjs\node_modules\kew\kew.js:92:25)
    at resolver (C:\Users\Tandy7\AppData\Roaming\npm\node_modules\karma-phantomj
s-launcher\node_modules\phantomjs\node_modules\kew\kew.js:264:17)
    at ReadStream.cb (C:\Users\Tandy7\AppData\Roaming\npm\node_modules\karma-pha
ntomjs-launcher\node_modules\phantomjs\node_modules\ncp\lib\ncp.js:217:38)
npm ERR! error rolling back Error: ENOTEMPTY, rmdir 'C:\Users\Tandy7\AppData\Roa
ming\npm\node_modules\karma-phantomjs-launcher\node_modules\phantomjs\lib\phanto
m'
npm ERR! error rolling back  phantomjs@1.9.2-2 { [Error: ENOTEMPTY, rmdir 'C:\Us
ers\Tandy7\AppData\Roaming\npm\node_modules\karma-phantomjs-launcher\node_module
s\phantomjs\lib\phantom']
npm ERR! error rolling back   errno: 53,
npm ERR! error rolling back   code: 'ENOTEMPTY',
npm ERR! error rolling back   path: 'C:\\Users\\Tandy7\\AppData\\Roaming\\npm\\n
ode_modules\\karma-phantomjs-launcher\\node_modules\\phantomjs\\lib\\phantom' }
npm ERR! error rolling back Error: EPERM, unlink 'C:\Users\Tandy7\AppData\Roamin
g\npm\node_modules\karma-phantomjs-launcher\node_modules\phantomjs\lib\phantom\p
hantomjs.exe'
npm ERR! error rolling back  karma-phantomjs-launcher@0.1.0 { [Error: EPERM, unl
ink 'C:\Users\Tandy7\AppData\Roaming\npm\node_modules\karma-phantomjs-launcher\n
ode_modules\phantomjs\lib\phantom\phantomjs.exe']
npm ERR! error rolling back   errno: 50,
npm ERR! error rolling back   code: 'EPERM',
npm ERR! error rolling back   path: 'C:\\Users\\Tandy7\\AppData\\Roaming\\npm\\n
ode_modules\\karma-phantomjs-launcher\\node_modules\\phantomjs\\lib\\phantom\\ph
antomjs.exe' }
npm ERR! weird error 1
npm ERR! not ok code 0

C:\Users\Tandy7>

This is in a fresh Windows 7 VM and I followed this guide for setting up my environment: https://gist.github.com/nullivex/7115612

If you would like access to the VM message me off list.

nullivex · 2013-11-10T20:47:23Z

Here is a screenshot

isaacs · 2013-11-13T18:02:06Z

@nullivex Take a look at that stack trace. The problem is in the karma/phantomjs install script. I'll take a look at this when I get a chance, but my best guess is that it's trying to delete a dir that's currently being written to.

nullivex · 2013-11-13T20:41:25Z

Yeah that's what we figured as well. Again I'm not sure where the fix would
go just trying to centralize this problem as a couple issues point to it.

I believe what is happening is that when phantomjs or any other package
comes with an executable the AV starts scanning it which most likely leaves
the directory unclean causing the error.

I'd be happy to try to work out a pull request against phantomjs if we can
narrow down how it's being used incorrectly. Certainly the developers
assumed there wouldn't be anyone else in the directory they were working in.

However since AV programs are really common for windows users it is worth
fixing in my opinion.

On Wednesday, November 13, 2013, Isaac Z. Schlueter wrote:

@nullivex https://github.com/nullivex Take a look at that stack trace.
The problem is in the karma/phantomjs install script. I'll take a look at
this when I get a chance, but my best guess is that it's trying to delete a
dir that's currently being written to.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-28417969
.

eSited LLC
(701) 390-9638

jbondc · 2013-11-14T14:19:59Z

There's a similar issue here:
https://issues.apache.org/jira/browse/CB-5330

To reproduce:

wget https://github.com/apache/cordova-cli/archive/master.zip
unzip master.zip
cd cordova-cli-master
npm update
npm test

...................................................................................rm: could not remove directory (code ENOTEMPTY): Z:\cordo
va-cli-master\temp/.cordova/hooks/before_build

rm: could not remove directory (code ENOTEMPTY): Z:\cordova-cli-master\temp/.cordova/hooks/before_build
rm: could not remove directory (code ENOTEMPTY): Z:\cordova-cli-master\temp/.cordova/hooks

rm: could not remove directory (code ENOTEMPTY): Z:\cordova-cli-master\temp/.cordova/hooks/before_build
rm: could not remove directory (code ENOTEMPTY): Z:\cordova-cli-master\temp/.cordova/hooks
rm: could not remove directory (code ENOTEMPTY): Z:\cordova-cli-master\temp/.cordova

rm: could not remove directory (code ENOTEMPTY): Z:\cordova-cli-master\temp/.cordova/hooks/before_build
rm: could not remove directory (code ENOTEMPTY): Z:\cordova-cli-master\temp/.cordova/hooks
rm: could not remove directory (code ENOTEMPTY): Z:\cordova-cli-master\temp/.cordova
rm: could not remove directory (code ENOTEMPTY): Z:\cordova-cli-master\temp

.{ [Error: EPERM, operation not permitted 'Z:\cordova-cli-master\temp.cordova\hooks\before_build\fail.bat']
errno: 50,
code: 'EPERM',
path: 'Z:\cordova-cli-master\temp.cordova\hooks\before_build\fail.bat',
syscall: 'stat' }

The tests work fine on linux, I traced it down to code that tries to recursively remove a directory in 'shelljs'.

What happens is:

a) File is deleted (before_build\fail.bat)
https://github.com/arturadib/shelljs/blob/master/src/rm.js#L126

b) Removal of directory fails with ENOTEMPTY
https://github.com/arturadib/shelljs/blob/master/src/rm.js#L141

At the last failure:
https://github.com/arturadib/shelljs/blob/master/src/rm.js#L15

fs.readdirSync(dir) reports the file as existing! so fs.lstatSync() throws [Error: EPERM, operation not permitted

This points to node on Windows either:
a) fs.unlinkSync() is successful but directory entry still exists
b) fs.readdirSync(dir) is using some cached / old entry of directory info?

I think it's more (b) since I tried adding sleep(5) and doesn't change the fact the directory entry still thinks the file exists.

jbondc · 2013-11-14T18:14:18Z

I give up, best next guess is a bug in libuv:
https://github.com/joyent/libuv/blob/master/src/win/fs.c#L742

I'm not sure what FindFirstFileW and FindNextFileW are doing, from what I can tell, the win32 api is FindFirstFile, FindNextFile?

nullivex · 2013-11-14T20:42:43Z

@jbondc Do you have any AV installed? Or any other program that actively monitors certain file types like executables (.bat, .exe, etc). I have only seen this occur when someone has an AV that scans executable's.

jbondc · 2013-11-14T21:08:10Z

On Windows 8.1, if I disable:

Windows Defender (no spyware, no virus protection)
Windows Search

I get the same result. Here's what the order of operations looks like:
http://sdrv.ms/HW49Re

nullivex · 2013-11-15T01:52:11Z

Strange everything for me seems to work fine on windows 8 as long as I dont have an AV enabled. And the fact that its happening with a .bat leads me to believe that maybe that bat file hadnt finished executing or something is scanning it not sure.

But overall @isaacs I guess we really need some way to block until all the file handles have free'd up for things to work as expected? Just brainstorming.

jbondc · 2013-11-15T14:37:12Z

I get the same result in Windows 7, really odd.

Maybe some answers here:
http://blogs.msdn.com/b/oldnewthing/archive/2011/12/26/10251026.aspx

But using a FAT filesystem, I get the same result.
Signs point to weird stuff node is doing to make the 'async' appear synchronous.

unlink on UNIX:
https://github.com/joyent/libuv/blob/master/src/unix/fs.c#L921

unlink for windows:
https://github.com/joyent/libuv/blob/master/src/win/fs.c#L1608
https://github.com/joyent/libuv/blob/master/src/win/fs.c#L635

The unlink for windows is more complex, maybe a timing/thread issue there. I'm just guessing.

jbondc · 2013-11-15T15:08:48Z

Maybe relevant for 'FindFileFirst':
"In rare cases, file attribute information on NTFS file systems may not be current at the time you call this function. To be assured of getting the current NTFS file system file attributes, call the GetFileInformationByHandle function."

http://msdn.microsoft.com/en-us/library/windows/desktop/aa364952%28v=vs.85%29.aspx

piscisaureus · 2013-11-15T15:41:05Z

None of the above.

ENOTEMPTY is in fact a condition similar to EBUSY that can happen on directories.

When a file is deleted while another handle or another process still has the file open, the file just gets 'marked for deletion'. The directory entry remains until the file is actually deleted, which happens when the last handle to it is closed.

This is unlike unix where the inode has the same semantics of a file on windows (it isn't actually deleted until all FDs are closed), but the directory entry can be removed immediately.

Note that this case is also distinct from the EBUSY case - that happens when deletion itself is prevented by another process that did not set the FILE_SHARE_DELETE flag when opening the file. But it's likely that virus scanners set the flag when opening files to be scanned, so antivirus software might indeed trigger this.

(and yes, it is dumb)

jbondc · 2013-11-15T16:09:49Z

But which handle or process still has the file open? It appears that only node is accessing those files.
http://sdrv.ms/HW49Re

Should CloseHandle() be before SET_REQ_SUCCESS() ?

https://github.com/joyent/libuv/blob/master/src/win/fs.c#L693

piscisaureus · 2013-11-15T16:21:44Z

But which handle or process still has the file open? It appears that only node is accessing those files.
http://sdrv.ms/HW49Re

The virus scanner, that starts scanning the file in response to it being created.

http://sdrv.ms/HW49Re

It probably won't show up so near to the node action. But I can't look through that file and have only your screen shot to go by.

Should CloseHandle() be before SET_REQ_SUCCESS() ?
https://github.com/joyent/libuv/blob/master/src/win/fs.c#L693

no. throwing shit at the wall doesn't really help.

isaacs · 2013-11-15T16:56:36Z

Thanks for the feedback, @piscisaureus.

ENOTEMPTY is in fact a condition similar to EBUSY that can happen on directories.

So, for rimraf's purposes, much as it pains me, should we just keep trying for a while like we do with EBUSY?

Of course, I wouldn't ever want to do such a thing on Unix, but if it would work around a windows-specific issue, then that's probably fine.

piscisaureus · 2013-11-15T17:01:39Z

So, for rimraf's purposes, much as it pains me, should we just keep trying for a while like we do with EBUSY?

Right on. Unfortunately there is no good way to tell this case apart of a real ENOTEMPTY condition, and it's hard to tell what is an appropriate time to retry. Not anything that isn't very complex atleast.

So yeah, just keep trying for a while...

Of course, I wouldn't ever want to do such a thing on Unix, but if it would work around a windows-specific issue, then that's probably fine.

jbondc · 2013-11-15T18:25:13Z

Fair enough, but I'm pretty sure this case has nothing to do with the virus scanner:
https://skydrive.live.com/?cid=295047487FC4F731&id=295047487FC4F731%213386&v=3

I put up the log files here:
http://sdrv.ms/17wmVob

Can also export in csv or xml.

piscisaureus · 2013-11-15T19:13:33Z

@jbondc It seems that in this case node has the file open when it gets deleted. So you get the same effect.

* Delete folder that works on windows (isaacs/rimraf#25) * . Co-authored-by: Håkansson Lars IT-konsulter <lars.hakansson@guest.skogsstyrelsen.se>

shama mentioned this issue Sep 10, 2013

Keep getting ENOTEMPTY error. Unable to delete directories. gruntjs/grunt-contrib-clean#34

Closed

mlarcher mentioned this issue Nov 8, 2013

1.9.2-2 install error on Win7 x64 Medium/phantomjs#108

Closed

isaacs closed this as completed Nov 8, 2013

jbondc referenced this issue in joyent/libuv Nov 15, 2013

windows: fix flags assignment in uv_fs_readdir()

bdc8289

isaacs reopened this Nov 28, 2013

isaacs closed this as completed in d819b12 Nov 29, 2013

debajyotimahanta mentioned this issue May 22, 2014

Windows: Warning: Unable to delete ".tmp" file (ENOTEMPTY, directory not empty gruntjs/grunt-contrib-clean#47

Closed

scmx mentioned this issue Jun 25, 2014

npm WARN deprecated gulp-clean@0.2.4: use gulp-rimraf instead slushjs/slush-angular#21

Closed

kevinsawicki mentioned this issue Oct 24, 2014

Experience Feedback atom/atom#3941

Closed

joliss mentioned this issue Mar 21, 2015

Windows support (ENOTEMPTY issues) #72

Closed

icnocop mentioned this issue Jun 10, 2015

0x80070091 - Error deleting directory: C:\Users\UserName\AppData\Local\Temp\{GUID}: The directory is not empty. dotnetinstaller/dotnetinstaller#88

Open

gkorland mentioned this issue Sep 15, 2015

ENOTEMPTY is thrown on removeSync jprichardson/node-fs-extra#178

Closed

sod mentioned this issue Feb 11, 2016

Failing to clear installed dependencies swarajban/npm-cache#43

Open

chayeon mentioned this issue Nov 3, 2016

EBUSY is not handled properly in SmartOS(Solaris) enviroment. #123

Closed

RyanZim mentioned this issue Nov 22, 2016

move with clobber option 'ENOTEMPTY' jprichardson/node-fs-extra#124

Closed

ronniegane mentioned this issue May 4, 2017

Error during ng build: ENOTEMPTY "...\public\ui\" lbialy/play-ng2-webpack2#7

Open

diracdeltas mentioned this issue May 17, 2017

fix 'Error: ENOTEMPTY: directory not empty' test errors brave/browser-laptop#8915

Merged

hezedu mentioned this issue Sep 21, 2017

目录层次太多时会删除失败 hezedu/fuckwinfsdel#1

Closed

laurenzlong mentioned this issue Nov 28, 2017

Can't deploy functions. Error: ENOTEMPTY: directory not empty, rmdir... firebase/firebase-tools#549

Closed

lars-hakansson pushed a commit to lars-hakansson/ng-openapi-gen that referenced this issue Apr 27, 2020

Delete folder that works on windows (isaacs/rimraf#25)

49a7a8c

lars-hakansson mentioned this issue Apr 27, 2020

Delete temp folder windows fix cyclosproject/ng-openapi-gen#97

Merged

luisfpg pushed a commit to cyclosproject/ng-openapi-gen that referenced this issue Apr 27, 2020

Delete temp folder windows fix (#97)

65d395e

* Delete folder that works on windows (isaacs/rimraf#25) * . Co-authored-by: Håkansson Lars IT-konsulter <lars.hakansson@guest.skogsstyrelsen.se>

IDCs mentioned this issue Jun 16, 2020

error: ENOTEMPTY: directory not empty, rmdir 'C:\Users\jason\AppData\Roaming\Vortex\skyrimse\mods\ApachiiSkyHairFemale_v_1_5_Optimized-2014-1-5\meshes\ApachiiHairFemale\Human' Nexus-Mods/Vortex#6548

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Doesn't work #25

Doesn't work #25

Petah commented Jul 9, 2013

isaacs commented Jul 11, 2013

Petah commented Jul 11, 2013

mlarcher commented Nov 8, 2013

isaacs commented Nov 8, 2013

isaacs commented Nov 8, 2013

Petah commented Nov 9, 2013

nullivex commented Nov 10, 2013

isaacs commented Nov 10, 2013

nullivex commented Nov 10, 2013

isaacs commented Nov 10, 2013

nullivex commented Nov 10, 2013

isaacs commented Nov 10, 2013

nullivex commented Nov 10, 2013

nullivex commented Nov 10, 2013

nullivex commented Nov 10, 2013

isaacs commented Nov 13, 2013

nullivex commented Nov 13, 2013

jbondc commented Nov 14, 2013

jbondc commented Nov 14, 2013

nullivex commented Nov 14, 2013

jbondc commented Nov 14, 2013

nullivex commented Nov 15, 2013

jbondc commented Nov 15, 2013

jbondc commented Nov 15, 2013

piscisaureus commented Nov 15, 2013

jbondc commented Nov 15, 2013

piscisaureus commented Nov 15, 2013

isaacs commented Nov 15, 2013

piscisaureus commented Nov 15, 2013

jbondc commented Nov 15, 2013

piscisaureus commented Nov 15, 2013

Doesn't work #25

Doesn't work #25

Comments

Petah commented Jul 9, 2013

isaacs commented Jul 11, 2013

Petah commented Jul 11, 2013

mlarcher commented Nov 8, 2013

isaacs commented Nov 8, 2013

isaacs commented Nov 8, 2013

Petah commented Nov 9, 2013

nullivex commented Nov 10, 2013

isaacs commented Nov 10, 2013

nullivex commented Nov 10, 2013

isaacs commented Nov 10, 2013

nullivex commented Nov 10, 2013

isaacs commented Nov 10, 2013

nullivex commented Nov 10, 2013

nullivex commented Nov 10, 2013

nullivex commented Nov 10, 2013

isaacs commented Nov 13, 2013

nullivex commented Nov 13, 2013

jbondc commented Nov 14, 2013

jbondc commented Nov 14, 2013

nullivex commented Nov 14, 2013

jbondc commented Nov 14, 2013

nullivex commented Nov 15, 2013

jbondc commented Nov 15, 2013

jbondc commented Nov 15, 2013

piscisaureus commented Nov 15, 2013

jbondc commented Nov 15, 2013

piscisaureus commented Nov 15, 2013

isaacs commented Nov 15, 2013

piscisaureus commented Nov 15, 2013

jbondc commented Nov 15, 2013

piscisaureus commented Nov 15, 2013