Sender:	vheyndri AT rug DOT ac DOT be
Message-Id:	<349A2FE7.2870@rug.ac.be>
Date:	Fri, 19 Dec 1997 09:27:19 +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 971218132915 DOT 1611T-100000 AT is>

Eli Zaretskii wrote:
> 
> On Thu, 18 Dec 1997, Vik Heyndrickx wrote:
> 
> > But ,why is a trick needed? If a file shouldn't be opened for reading,
> > then why try to get around that?
> Because it doesn't make sense to be unable to open a file for read-only
> access, IMHO.  Doing so won't hurt anybody but the one who opened it in
> read-only mode (if they assume that they see the up-to-date file
> contents).  

Ok, suppose that WinWord wants to open a file for editing: it opens it
disallowing further read or write access until the editing is done and
the file has been closed again. If it does not disallow this, a program
can read this file while it is written, the contents are not only not
up-to-date but can also be contradictory. e.g. when a djgpp program
would make a backup of all files in a directory, this behaviour would be
the most undesirable one. IMHO, this is what file sharing is all about
and it should not be touched.

>             And Windows actually allows this, *if* you open the file in
> DENYNONE sharing mode.  

AFAIK the sharing mode does only affect file operations AFTER this open.

>                        So `open' in v2.02 first tries to open the file
> as usual, and if that fails, and if no sharing bits were specified, tries
> again with DENYNONE.  

It seems to me that this sharing mode is misinterpreted, or am I wrong?

> > > 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)
> 
> What I saw was that when I have a file open by Less in one DOS box, Emacs
> in another DOS box cannot save the buffer which visits that file.  I have
> decided, possibly mistakenly, that this is because the open call fails.

According to the Acc/Shr table at least these 2 opens should work
without failure. I would not know why exactly this fails.

> It might as well be that when Emacs tries to rename the old version,
> Windows refuses the call; I never dug into Emacs to see what actually
> fails there.

When sharing in installed, renaming and moving files that are open will
fail with access code 0x05.
Considering the fact that the only thing Emacs cannot do is making
coffee, I understand :-)

> Did you actually try to write to a file that is open by another DOS box,
> or only to open it?  If the latter, please try to write and see if
> Windows lets you.

All opens and writes were made using the same conditions as in the
interrupt list, presumably. It would be interesting to see what happens
when both opens were executed from a different DOS box. I strongly
suspect exactly the same results.

> Did you try to read/write, or just to open?

Just open. If Windows would allow me to open a file first for writing or
r/w, and afterwards does not allow me to write to it, I should consider
this a bug... so I probably better try to write to it.

> > - Win 95 automatically generate FAIL on INT24.
> That might only be true for DJGPP (DPMI) programs.  CWSDPMI does the
> same.

Ill-considered by me, you're probably right.

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

- Raw text -