Re: win32 open patch for held unlink

> But I do think you should handle permission denied errors a bit more
> gracefully, don't you think? Not exactly an uncommon error, and it would
> certainly help to get the correct errno set there so you get a decent
> error msg back in the caller.
> Probably also ERROR_PATH_NOT_FOUND. The rest can be "generalised" into
> one, since they don't occur very often.

Point taken (I modelled it originally on just a replacement for the open in
BasicOpenFile, hence the arguably missing error checks, but since we are
making it generic...). So, you reckon a EACCES on ERROR_ACCESS_DENIED or
ERROR_PATH_NOT_FOUND should do the trick?

> Also (not sure about this one - so correct me if I'm wrong), shouldn't
> errno be set to *something* upon error when you haven't set a specific
> error?

I was hoping to get a full enumeration here, so that this case would never
occur (and then promptly forgot to finish it off, it would appear :-). Happy
to suggest a default errno if you can suggest one? [not sure there is a good
default for open()]

> One other question: The _open_osfhandle docs don't really tell about how
> to *close* the handle. Have you verified that you don't need to create a
> separate close functino that will do CloseHandle() as well on it? Or do
> we know that the system will do that for us when we close it? (I see
> some google refs to _close() calling CloseHandle(), but no official
> docs.

I confirmed this as I was writing + testing the code. close() appears to
CloseHandle, so we only need to worry about it if we decide to bail between
the CreateFile() and _open_osfhandle [good pickup though].

Cheers,
Claudio

---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>