Sender: vheyndri AT rug DOT ac DOT be
Message-Id: <3510E470.5F2@rug.ac.be>
Date: Thu, 19 Mar 1998 10:25:04 +0100
From: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version: 1.0
To: djgpp-workers AT delorie DOT com
Cc: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, SET <salvador AT inti DOT gov DOT ar>
Subject: DOS sharing behaviour, a guide
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi workers,

Since RBIL's list on sharing behaviour is not entirely correct (i.e.
complete), it is difficult to decide how files should be opened.
Below follows the result of a LOT of work. I've drawn my conclusion HOW
to open files, I hope you'll make the same conclusions.

First:
the read-only bit is stricktly spoken not part of the file sharing
protocol, never. This means that if a file has that bit set, it cannot
be opened in a mode that includes writing, except on time of creation of
course.
Please note below here that I completely ignore the existence of this
bit.

Second:
* if no sharing is installed (SHARE.EXE, vshare.386 or whatever):
DOS can't care less what we pass as sharing mode, it simple ignores it
and a consecutive open always succeeds. DOS is not a protective
operating system, isn't it.
* with SHARE.EXE from DOS6.22:
a second open in compatibility mode always fails, or when the first open
was in compatibility mode this second open also fails always. There is
nothing we can do about that (in the second program).
* with vshare.386 in Win3.1
a second open in compatibility mode always fails when the first file was
also opened in compatibility mode, except when both prg's opened the
file for reading only.
* Win95
identical to vshare.386 from Win3.1 when it concerns the fact whether an
open command succeeds. It also has a fourth access mode, but of less
importance to us.

Third:
Remark: when the second upon occurs in the same program in compatibility
mode the call usually succeeds, from a different program usually not.

A file that just has been created (with CREAT, CREATNEW, CREATTEMP) can
be considered as being opened for r/w in compatibility mode (which is
the same as r/w + deny-read) (Eli, that where you asked for).

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.

Preliminary conclusions:
if we have to open a file for:
	reading
		open it for reading and specify DENYWRITE (that avoids the SET patch)
	writing
		open it for writing and specify DENYALL
        r/w
		open it for r/w and specify DENYALL
This way we INCREASE the chance that a file can be opened
successfully.        

That's all, If you've questions or remarks feel free to ask me
personnaly. When it contains something it concerns us all I'll CC
workers.

-- 
 \ Vik /-_-_-_-_-_-_/   
  \___/ Heyndrickx /          
   \ /-_-_-_-_-_-_/