Date: Mon, 3 May 1999 16:27:27 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: DJ Delorie <dj AT delorie DOT com>
cc: djgpp-workers AT delorie DOT com
Subject: Re: Windows 9X bug when it runs out of file handles
In-Reply-To: <199905031233.IAA22283@envy.delorie.com>
Message-ID: <Pine.SUN.3.91.990503161002.28971D-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Mon, 3 May 1999, DJ Delorie wrote:

> I was hoping for something like this:
> 
> fd = open(...);
> if (fd == -1)
> {
>   if (errno == ESHARE)
>     open(...,SH_DENYNO)
>   else if (errno == ENOFILE)
>     _creat(...);

The first version I wrote went something like that; but then I got scared
of introducing new bugs, because we don't actually know what kind of
weirdo errno values we could get in every situation. 

Take the sharing violation, for example.  We'd probably get the
ubiquitous EACCES; but who's to say it will be *always* EACCES?  Maybe 
we will have something exotic like EXDEV or EIO?  Furthermore, if we do 
get EACCES, does that mean DENY-NONE is the right thing to do? 

Even the simpler ENOENT case might have its pitfalls.  If you remember, 
we had some Novell client that reported ENOENT inside `_rename' even 
though the file actually existed (so we now have a special case just for 
that).  If we call `_creat' whenever we get ENOENT, we risk nuking the 
file's contents in such cases.

So I got cold feet (this is just a bugfix release, right?) and opted for 
a safer way:

	- if it's EMFILE/ENFILE, there's nothing else to do but fail;
	- if `__file_exist' says the file doesn't exist, call `_creat';
	- else try DENY-NONE, unless we already tried some share bits.