www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1997/12/18/03:39:27

Sender: vheyndri AT rug DOT ac DOT be
Message-Id: <3498E0E5.6960@rug.ac.be>
Date: Thu, 18 Dec 1997 09:37:57 +0100
From: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc: djgpp-workers AT delorie DOT com
Subject: Re: Q?on sharing/locking files
References: <Pine DOT SUN DOT 3 DOT 91 DOT 971217131702 DOT 28623A-100000 AT is>

Eli Zaretskii wrote:
> 
> On Wed, 17 Dec 1997, Vik Heyndrickx wrote:
> 
> I'm not sure.  Why should `fopen' deny any access rights when neither
> ANSI nor POSIX require that?  

They require, neither forbid that AFAIK. So it is up to us to choose,
IMHO.

>                              If somebody wants specific access rights,
> they should use `open' or `_open', IMHO. 

That is one possibility. The user can even create a FILE descriptor from
a handle returned by open. 

> There are two many different
> programs on a typical PC, compiled with too many different libraries,
> each one with its own peculiar default access rights.  

There is nothing peculiar about the defaults *I* propose. The only thing 
that can happen is that these defaults can prevent a file from being
trashed.

> The best way to
> deal with that is to use the most compatible mode, which is waht we do.
> (Recently, it turned out that documents open by WinWord cannot be open
> even for read-only access by DJGPP programs, so v2.02 will include a
> trick to work around such cases.)

Now I understand why the WordReader comes with a SHARE.EXE and
SHARE.386.

But ,why is a trick needed? If a file shouldn't be opened for reading,
then why try to get around that?

> > Specifying the sharing modes would at least not harm anyone if share
> > were not installed (Win95 has it always installed, I think).
>                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Exactly.  Therefore, you should assume that sharing is always installed.
> Even plain DOS systems usually install it, as far as my experience goes:
> some of them are leftovers from DOS 4.0, others installed Windows 3.1
> which adds SHARE, Windows 3.11 has VSHARE, just like 95, etc.

Amazingly enough, I just discovered that DOS 7.1 does not have a
SHARE.EXE!
I have a copy of Win3.1 which does NOT install share (although
share.386) is included.
 
> > What do you mean with "no problems"? I think that in compatibity mode,
> > one area of the file can be written and read at the same time
> > (pseudo), with evidently funny results.
> 
> At least Windows95's VSHARE doesn't allow that, as I described.

This is incorrect. In compatibility mode all access request are granted
(both files opened in compat. mode)

> > I'll check whether this is possible. Just to understand completely well,
> > you say that a file opened in compat. mode, yields EACCESS when a
> > consecutive open-write is issued?
> 
> That is how the Interrupt List describes the situation.  

This is incorrect, (I'm referring to release 55)

>                                                         There is a
> compatibility matrix there, near the docs of OpenFile DOS function
> (AH=3Ch, if memory serves).  It would be interesting to see how true it
> is.  According to my limited testing on Windows 95, it is not 100%
> correct.

I did my homework:
It is completely correct, except:
- if one file is opened for reading with DENY_NONE, the other file can
be opened 
in compatibility mode as for R, W as RW.
- the '1' and '2', should be simply 'Y'
- Win 95 automatically generate FAIL on INT24.
- It is incomplete (Win95 has a fourth access mode)
 
> I'd recommend not to use locking, on Unix also, unless the programs which
> access the shared files are cooperative, i.e., if they all call `lockf'
> before trying to open the file.

The 'other' program is an instance of the same program.

> > Isn't there anything Emacs doesn't have?
> 
> Maybe, but I haven't found it yet ;-).  Oh, yes: it cannot make coffee.

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019