Message-Id: <m0xzHm5-000S4NC@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>, djgpp-workers AT delorie DOT com
Date: Mon, 2 Feb 1998 12:12:49 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: fopen and shared files question
References: <m0xyHnZ-000S2dC AT inti DOT gov DOT ar>
In-reply-to: <Pine.SUN.3.91.980201200029.16390Q-100000@is>
Precedence: bulk

Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
> On Fri, 30 Jan 1998, Salvador Eduardo Tropea (SET) wrote:
> 
> > I taked a look to the v2.02 alpha (980101) and the patch isn't
> > there.
> 
> You didn't try hard enough ;-).  The patch *is* there, but it is in
> `open', not in `fopen' (there's no sense in doing this in `fopen'
> alone).
Ops!
 
> > What I proposse:
> > The Eli/Michael's patch is good if the file was opened by other application
> > with the DENYWR flag, but not if the other application used the "compatible
> > mode". The last is the current status of djgpp programs. So two djgpp
> > programs doesn't get any benefit from this patch; and that's my
> > case.
> 
> Please try to understand and explain why does this happen.  According
> to my references, if two programs open a file in compatibility mode,
> both open calls should succeed (see the latest Ralf Brown's Interrupt
> List).  So I don't see how does the problem happen.  Can you post a
> simple test program and explain what exactly goes wrong?  In
> particular, are you sure that what fails is the open call, not the
> actual write call?
Is the read call the one that fails! seems to be related to SHARE.EXE. You can 
open the file, but you can't read from it, even when both programs opened for 
read. Only the first can read, the second gets something like Error 26 bad ...
 
> > That means: ever open the files trying to deny write access to other
> > applications and if it fails try to open it without any deny. (sorry for the
> > use of the deny word in this way).
> 
> According to the Interrupt List, this strategy will fail the open call
> in the second program in more cases than the current setup.  So it is
> actually worse than the current situation.
The code that I posted WORKS.
 
> > And yet another option is to add a special variable to control it.
> 
> You can always do this yourself, since `open' and `_open' don't mask
> away the sharing bits.  So if you need specific sharing bits to be
> set, you can do that: just use `open' (and then `fdopen', if you need
> to use buffered stdio functions).  There is no need to change anything
> in the library to get this flexibility.
But in this way I must isolate the code and put
#ifdef __DJGPP__ ...
and I don't like it.

The code I posted fixes the problem, two copies of the editor can open the help 
files and read the help files.

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