Mail Archives: djgpp-workers/1997/12/17/06:31:41
On Wed, 17 Dec 1997, Vik Heyndrickx wrote:
> 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
I'm not sure. Why should `fopen' deny any access rights when neither
ANSI nor POSIX require that? If somebody wants specific access rights,
they should use `open' or `_open', IMHO. 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. 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.)
> 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.
> 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.
> 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. 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.
> 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).
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.
> > (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.
Please consider submitting that version to DJ, for inclusion in v2.02.
> Having better specs would be a must, though.
"man lockf" should do. It's really quite a simple function, and the DOS
equivalent is functionally identical. All you need is to call `ltell'
and then call `lock'.
> It should at least work under some conditions reliable, else there is no
> purpose of having locking functions?
It works if the programs query the locking state before they try to open
the file. Thus this locking is called ``advisory''. DOS and Windows are
more stringent.
> > 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?
Maybe, but I haven't found it yet ;-). Oh, yes: it cannot make coffee.
- Raw text -