Message-Id: <m0y1nQ1-000S1oC@inti.gov.ar>
Comments: Authenticated sender is <salvador AT natacha DOT inti DOT gov DOT ar>
From: "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>
Organization: INTI
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Date: Mon, 9 Feb 1998 10:22:02 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: fopen and SHARED files
CC: djgpp-workers AT delorie DOT com
References: <m0y0oup-000S2tC AT inti DOT gov DOT ar>
In-reply-to: <Pine.SUN.3.91.980208135645.6339S-100000@is>
Precedence: bulk

Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
> 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.

Yes perhaps a full compatibility could be better.
 
> >   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.

Ok, making 0 as default it will be OK.
 
> >   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.

Ok, I'll make such a patch.

SET 
------------------------------------ 0 --------------------------------
Visit my home page: http://set-soft.home.ml.org/
or
http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-sot AT usa DOT net - ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013