std: Make unlink() more consistent

[alexcrichton]

Currently when a read-only file has unlink() invoked on it on windows, the call
will fail. On unix, however, the call will succeed. In order to have a more
consistent behavior across platforms, this error is recognized on windows and
the file is changed to read-write before removal is attempted.

[huonw]

Just for completeness: did you consider doing the reverse (rejecting unlink on a read-only file on unix)? If so, what was the reason for rejecting that?

[bill-myers]

@huonw That would be completely wrong in Unix, since unlink removes the name from the directory, which has nothing to do with whether the file is writable or not, but depends of course on whether the directory is writable or not.

@alexcrichton However, the code seems to suffer from race conditions, since it will fail if someone unsets the read-only attribute just after the unlink fails, but it looks like this race condition is unfixable if ERROR_ACCESS_DENIED is returned for other errors too (however, retrying N times might be better).

It appears, from web searches (https://vtopan.wordpress.com/2009/05/26/using-ntdeletefile-from-delphi/), that the NT API NtDeleteFile will delete read-only files too (and also delete the file immediately, like Unix): maybe that could be the best solution if it's indeed the case.

[alexcrichton]

Just for completeness: did you consider doing the reverse (rejecting unlink on a read-only file on unix)? If so, what was the reason for rejecting that?

I suppose I hadn't given it an overwhelming amount of thought, no! I suppose I conceptually would rather just delete a file when I call unlink rather than check whether it's actually writable, but I would suspect that I am mostly just biased towards unix.

[alexcrichton]

However, the code seems to suffer from race conditions

That is correct, and this was written with that in mind. I would think that essentially any filesystem interaction is inherently racy, however, so trying to protect this one case on windows may not be buying us much.

the NT API NtDeleteFile will delete read-only files too

Interesting! I was under the impression that Nt-prefix things were internal-use-only and weren't recommended for use? This is also a problem with libgreen and would require upstreaming something to libuv as well.