Date: Sun, 22 Mar 1998 15:26:48 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
cc: djgpp-workers AT delorie DOT com, SET <salvador AT inti DOT gov DOT ar>
Subject: Re: DOS sharing behaviour, a guide
In-Reply-To: <3510E470.5F2@rug.ac.be>
Message-ID: <Pine.SUN.3.91.980322152632.12122C-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Thu, 19 Mar 1998, Vik Heyndrickx wrote:

> The EXTENDED OPEN function is featurative or ***buggy*** (I'll decide
> upon that this weekend):
> You can successfully create a non-read/only file for reading only, and
> fail to write to it afterwards (see the reason why I need a weekend to
> decide whether it is a bug)
> Further details on this EXT. OPEN function will follow later on when
> they come in :-)
> Anyway some of our libc functions might fail because of this.

I'm not sure what these hints are about, but please keep in mind that
on LFN platforms we don't have anything *but* the extended open
function to work with.

Also, FAT32 support can only be gotten by using the extended function.
So if we ever want to support files larger than 2GB in plain DOS (no
Windows 9X), we will have to switch to the extended open function when
LFN is not available as well, somewhere in the (not-so-far) future.

> 	writing
> 		open it for writing and specify DENYALL
>         r/w
> 		open it for r/w and specify DENYALL

Doesn't this prevent other programs from opening the file in read-only
mode?