Skip to content

Commit

Permalink
Make rimraf.sync 10000% more reliable on Windows
Browse files Browse the repository at this point in the history
By retrying 100 times if we get an ENOTEMPTY removing a dir.
  • Loading branch information
isaacs committed Feb 18, 2017
1 parent e8b10a7 commit d53235d
Showing 1 changed file with 18 additions and 1 deletion.
19 changes: 18 additions & 1 deletion rimraf.js
Expand Up @@ -310,6 +310,7 @@ function rimrafSync (p, options) {
return isWindows ? fixWinEPERMSync(p, options, er) : rmdirSync(p, options, er)
if (er.code !== "EISDIR")
throw er

rmdirSync(p, options, er)
}
}
Expand Down Expand Up @@ -339,5 +340,21 @@ function rmkidsSync (p, options) {
options.readdirSync(p).forEach(function (f) {
rimrafSync(path.join(p, f), options)
})
options.rmdirSync(p, options)

// We only end up here once we got ENOTEMPTY at least once, and
// at this point, we are guaranteed to have removed all the kids.
// So, we know that it won't be ENOENT or ENOTDIR or anything else.
// try really hard to delete stuff on windows, because it has a
// PROFOUNDLY annoying habit of not closing handles promptly when
// files are deleted, resulting in spurious ENOTEMPTY errors.
var retries = isWindows ? 100 : 1
var i = 0
do {
try {
return options.rmdirSync(p, options)
} finally {
if (++i < retries)
continue

This comment has been minimized.

Copy link
@maartengo

maartengo Feb 13, 2020

I could be wrong, but this continue doesn't do anything except continue with the next loop. What it says right now is: if I didn't do X amount of retries, retry again, with implicit else: retry again (because while(true)).
This could be fixed by removing the if and changing the loop condition to i++ < retries:

  do {
    try {
      return options.rmdirSync(p, options)
    } finally {    }
} while (++i < retries)
}
} while (true)
}

1 comment on commit d53235d

@brucejo75
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @isaacs,
Recommend that you test this Windows issue with the following environment:

  • With full Defender Real-time protection on.
  • Running on a slow HDD (e.g. 5400 RPM used by laptops).

I think these 2 attributes can expose timing issues with the Windows file handles.

Please sign in to comment.