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?

Yes on ACCESS_DENIED. No on PATH_NOT_FOUND - different thing IMHO :)

My man page on Linux seems to suggest ENOENT is correct for
PATH_NOT_FOUND ("..Or, a directory component in pathname does not
exist..").


> > 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()]

Don't really know a good default there.. Perhaps something catch-all
like EINVAL (sort of like the common "The parameter is incorrect" on
win32.)

Full enumeration of all error codes on win32? That could be put in a
separate functino and used on other places, but really, there are a
*LOT* of error codes to convert... While some of them would be really
weird as return values for CreateFile(), I don't think there is a list
of which return codes can occur from that function specifically...


> > 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].

Ok. Great.

//Magnus