Mail Archives: djgpp-workers/1998/02/01/13:48:22
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).
> 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?
> 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.
> 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.
- Raw text -