ensureDir and ensureDirSync are racy

[lucacasonato]

They do lstat then mkdir rather than doing only mkdir and throwing an error.

If you call ensureDir quickly enough in parallel, one of the two ensureDir's will throw "AlreadyExists".

"exists" checks using something like lstat are wrong 99% of times, and this is no exception :)

[kt3k]

We switched the order of mkdir and lstat in #3242, but that caused another DX problem. Now ensureDir always asks for write permission to the given directory even when the directory already exists and it actually doesn't need to write to it.

Now a PR was created to mitigate that situation, but the solution looks very complex. #4008

Should we follow the direction of #4008 or should we revert back to pre-#3242 state, accepting some racy nature of it?

(In my view, ensureDir is usually called for creating special purpose paths such as cache dir, config dir, etc. I can't imagine ensureDir is called in high concurrency. We can also document that it can be racy in highly concurrent situation)

[iuioiua]

Accepting the racy nature of the function seems more reasonable and better than a complex solution as long as there's clear notice within the documentation, like exists().

[lucacasonato]

These functions should not be racy. If that means you sometimes need write permissions instead of read permissions, that seems like a reasonable trade-off to me.

[lucacasonato]

@kt3k i opened this bug because I was using it in high concurrency and my code would randomly crash. I think this function being racy is not acceptable.