Date:	Sun, 8 Feb 1998 13:57:06 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	"Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: fopen and SHARED files
In-Reply-To:	<m0y0oup-000S2tC@inti.gov.ar>
Message-ID:	<Pine.SUN.3.91.980208135645.6339S-100000@is>
MIME-Version:	1.0

On Fri, 6 Feb 1998, Salvador Eduardo Tropea (SET) wrote:

>   Windows 95 interprets the compat mode as "DENY WRITE", that means: if a
> djgpp program uses the compat mode to open a file (for read only) then other
> djgpp tasks can only open the file for reading. That means: other tasks can't
> write to the file.

This is not entirely correct, AFAIK.  Under Windows 95, when a file is
open in compatibility mode, other programs *can* open it in write (or
read/write) mode; but when the other program tries to actually write
to the file, it gets an error code (EACCES).  However, as soon as the
first program closes the file, the second one *can* write to it using
the same handle it got from the original `open' call.

In contrast, DENY WRITE will fail the attempt to open the file, which
is quite different, at least in the case that different programs
access files for short periods of time (i.e., if they use the
open/read/close paradigm).  Another case which will fail is when the
same program opens the same file more than once.

I am not sure whether this change will not break something, since the
code that reads from or writes to the file can be quite far (in both
time and source lines) from the code which opens the file.

> int __djgpp_share_mode=SH_DENYWR;

I think it is safer to make this 0 by default, so it would be
backwards-compatible to previous versions.

>   fd = open(file, oflags | __djgpp_share_mode, 0666);

I think it is wrong to add sharing bits unconditionally.  IMHO, it
should only be done if the user didn't request specific sharing bits.
If the user did, the exact sharing bits specified should be used.

>   The only problem I can see with that is if the user tries to open the same
> file two times in the same task (one for reading and the other for writing),
> with this new code it will fail, but I think that's better because the
> results of a success are unpredictable (the files are buffered by the libc).

The file is *not* buffered by the library if the program uses `read'
and `write', or lower-level calls.  It is IMHO incorrect to prevent
such code from working.

In sum, I think that adding the `__djgpp_share_mode' variable which
will default to zero, and using it inside `open' if the caller of
`open' didn't specify any sharing bits, is the best compromise.  I
suggest you submit a patch for `open' along these lines.

- Raw text -