Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!samsung!spool.mu.edu!sdd.hp.com!apollo!apollo.hp.com!pcc
From: pcc@apollo.HP.COM (Peter Craine)
Newsgroups: comp.sys.apollo
Subject: Re: File sharing across machines?
Message-ID: <50164f63.20b6d@apollo.HP.COM>
Date: 28 Feb 91 16:51:00 GMT
References: <1991Feb23.015726.8621@intek01.uucp>
Sender: root@apollo.HP.COM
Reply-To: pcc@1.COM
Organization: Hewlett-Packard Chelmsford Response Center
Lines: 50

In article <1991Feb23.015726.8621@intek01.uucp>, mark@intek01.uucp (Mark
McWiggins) writes:
|> We're porting a C-tree multiuser application to the Apollo.  C-tree opens
|> files in O_RDWR mode.  This works fine for multiple processes on a single
|> machine, but the same process on another machine fails to open the file
|> with "Text file busy".
|> 
|> There must be a way around this, but what?  I don't see anything relevant
|> in TFM; We're running 10.3 with the BSD environment option, but the
|> same behavior occurs with System V.
|> 

I'm afraid that I've got some bad news for you.  Once you open a file for write
access on a node, the node that performs the "open" is the ONLY node that will
be able to access that file.

"But why can it work in NFS, but not in Domain?"

NFS is implemented in a client/server model [no kidding].  So, when a computer
accesses a file, it is really asking a daemon on the computer where the file
lives to access the file.   All accesses (read/write requests) are done through
the daemon, so there aren't really any contention problems.

Not so with Domain.  (Here we go again).  Domain/OS is a "single-level store"
Operating System.  That means that references to parts of your virtual address
space are really direct references to the disk objects that are mapped at
that portion.

Put another way, a disk file is "mapped" directly into your address space, and
modifications to that portion of your address space are considered to be
changes to that file.

When you modify a file (that is, change the portion of your address space where
the file is mapped), the ONLY machine that can be certain to have the most
recent version of the contents of the file is the one that modified the
contents.  (In time, the changes will make it back across the network to the
node where the file lives, but that's another story for another time.)

Because you can never get access to the most up-to-date information, the
designers of Domain (nay, really Aegis, for this design constraint was put in
at the beginning of the OS) decided that the only node that has access to a
file is the one which has it opened for write.

(I have a better description of all this in a short paper I wrote for a
customer once.  I'll have to see if I can find it.)

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    Peter Craine                +  "Agent Cooper, I am thrilled to pieces that
    Hewlett-Packard             +    the Dharma came to Hohoho, I really am."
    Chelmsford Response Center  +  *I* don't want my opinions.  Why would HP?