Sender:	vheyndri AT rug DOT ac DOT be
Message-Id:	<3497AB79.416C@rug.ac.be>
Date:	Wed, 17 Dec 1997 11:37:45 +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, DJ Delorie <dj AT delorie DOT com>
Subject:	Re: Q?on sharing/locking files
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 971216120649 DOT 25478A-100000 AT is>

Eli Zaretskii wrote:
> 
> On Mon, 15 Dec 1997, Vik Heyndrickx wrote:
> 
> > Can I expect that when I manage to open a file for writing with fopen,
> > that writing is inhibited by all other accesses to this file?
> 
> AFAIK, it's on OS- and compiler-dependent mess.
> 
> On Unix, for example, several processes can happily write to the same
> file with interesting results.

> On DOS and MS-Windows it depends on whether some kind of file-sharing
> (SHARE or VSHARE) is or isn't loaded, and what kind of sharing did you
> specify when you open a file.  

Since fopen does not allow to specify the sharing mode (AFAIK), wouldn't
it 
be better that more sensible defaults were chosen:
  open for reading -> deny write
  open for writing -> deny read & write

Would this break any code?
Specifying the sharing modes would at least not harm anyone if share
were 
not installed (Win95 has it always installed, I think).

>                               The default for DJGPP is to open files
> in Compatibility mode.  According to my references, this means that
> any other DJGPP program should have been able to open the same file
> and write all over it with no problems. 

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.
 
>                                         However, Windows 95 disallows
> any attempts to open the file in either write or append mode (which is
> quite wise, IMHO).  So even documented behavior is not always
> observed (or maybe I'm missing something).

I'm currently trying to test some file routines (bypassing any DJGPP
routine).
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?

> > Or should I lock the file, but how do I do this portably?
> 
> First, I'd suggest to try hard to stay away of this problem if you
> can, since even locking won't always solve possible conflicts (see
> below).  If the problem in point can be solved without requiring
> simultaneous file access, try that approach first.

The real reason why I asked this, was to test a program that should
eventually
run on Sun Sparc Solaris. Obviously not such a good idea to test this
with
DJGPP (or any DOS(y) compiler).

> If you do need to lock, use the functions `lock' or `_dos_lock' in the
> library (there are also corresponding unlock functions).  They aren't
> portable, but you could easily write a wrapper around them to have
> Unix-compatible `flock' and `lockf', which have similar functionality,
> but slightly different interface.
> 
> (Btw, DJ, why don't we have `lockf'?  My references seem to imply that
> it is POSIX.  Isn't it?)

Even if it wouldn't be, it would be helpful. Randy Maas sent to me a
version
of lockf. I'll see what I can do with it. 
Having better specs would be a must, though.

> You should know that on Unix also, locking files cannot ensure that
> two applications won't write to the same file.  

It should at least work under some conditions reliable, else there is no
purpose of having locking functions?

>                                                For starters, locking
> doesn't work reliably across networks, so any file in a volume mounted
> over NFS can be scrogged by two different programs.  

Very painful if you are installing Linux while the files are being
updated.

>                                                     Also, locking on
> Unix is ``advisory'': it requires that all the programs that access a
> file use calls to `lockf' to see which parts of it are locked, so it's
> only good enough for cooperative programs. 

For 'entire file' locking, I think that DOS does not have this
requirement 
(neither unix BTW). If we could only prevent 2 programs from opening a
file
so that there accesses may mutually influence each other badly, we were
one
step down the road, IMHO.
 
>                                            That is why every
> application that is serious about this issue implements its own
> locking mechanism (Emacs is one example).

Isn't there anything Emacs doesn't have?

> AFAIK, ANSI doesn't say anything about these issues.  DJ?

Regards.

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

- Raw text -