Skip site navigation (1) Skip section navigation (2)

Re: win32 open patch for held unlink

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Claudio Natoli" <claudio(dot)natoli(at)memetrics(dot)com>
Cc: <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: win32 open patch for held unlink
Date: 2004-03-16 10:22:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers-win32
> > 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

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

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.


pgsql-hackers-win32 by date

Next:From: Claudio NatoliDate: 2004-03-16 10:33:20
Subject: Re: win32 open patch for held unlink
Previous:From: Claudio NatoliDate: 2004-03-16 09:22:25
Subject: Re: win32 open patch for held unlink

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group