Troubles opening the same file on 2 nodes

[Blair P. Houghton]

In article <1991Mar25.113854.6560 at athena.mit.edu> jik at athena.mit.edu (Jonathan I. Kamens) writes:
>In article <1991Mar24.191011.14552 at IRO.UMontreal.CA>, u715 at JSP.UMontreal.CA (Beliveau Steeve) writes:
>|> Hi!
>|> 	Here's a little program that will well explain my problem :
>
>  No, actually, it doesn't explain it very well at all, at least not as far as
>I can tell.

It's a mite clearer if you actually use Apollo machinery;
I'm lucky (sic) enough to, myself, so I understand what
he's saying, but I'm no Apollo-wizzie, so I refrained
(miracle of miracles! :) from responding.

>  What is the "test" file you're trying to open?  Is it a text file, or is it
>the binary you have compiled from the source code above?  Or something else?

Irrelevant to the situation; we can be sure here that
it's related to the OS and not the data.

>  Is the file on the local hard disk, or is it on a network file system disk? 
>If so, what kind of network file system?  NFS?  AFS?  Something else?

Something else, most definitely.

On an Apollo Domain/OS system, a "node" is a machine; ostensibly,
all Apollos can be connected all over the world; each has a unique
node_name built into it; this makes software licensing (especially
license timeouts) something of a cake-walk (though fiddling with
date(1) is always available).

Generally they're connected in a "ring" and very tightly
so; it's possible to access files on any node on the ring
simply by prefacing a pathname with "//node_name".  You could
get the same effect in NFS by making a directory /node_name
and nfs-mounting the root-directory from node_name onto it.
(Domain/OS, however, maintains links dynamically, apparently
using some sort of refresh system, and has a table-of-contents
database to cut down on file-retrieval time.  It's much niftier
than I can say adequately.  It's the networked fs NFS dreams
of becoming).

The ring is also a tighly coupled processing facility, allowing
somewhat transparent remote-cpu activity, but it's more like
rsh(1) than it should be, given the connectivity.

The system also implements a rather tight-fisted locking
system, which usually surprises me with its ability to
prevent access to a file.  Here we have a situation where
multiple read/write accesses from the local node are
permitted, but trying it simultaneously from different
nodes blows chunks.  (Just to say it "blows chunks" pretty
much stretches the depth of my understanding of the
network-locking-mechanism, so don't take my word for it).

>|> 	And the error is: Text file busy.
>|> 
>|> If I execute this program on the same node, on two different shell there is no errors. 
>|>   
>|> So what is the difference between excuting on the same or on two nodes?
>
>  If you're talking about a network file system, then is the file local on
>either of the machines you're running it on, or is it on a third-party
>fileserver?

That's entirely possible, too.

>  And I'm assuming that when you say "node," you mean machine on the network. 
>Is that correct?

On "a" network, but not necessarily the Internet.


My suggestion here is that our Canadian Friend take a look
over on comp.sys.apollo for the answer.  (I'd crosspost,
but something's wedged our nntp server, and half the groups
got blown away)


				--Blair
				  "I bet it was the number of
				   inodes being sucked-down by
				   alt.romance.chat..."