Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!mailrus!umich!terminator!dabo.ifs.umich.edu!rees
From: rees@dabo.ifs.umich.edu (Jim Rees)
Newsgroups: comp.sys.apollo
Subject: Re:  Subverting file locking mechanism
Message-ID: <1990Mar14.145858.26601@terminator.cc.umich.edu>
Date: 14 Mar 90 14:58:58 GMT
References: <9003131922.AA15055@richter.mit.edu>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rees@citi.umich.edu (Jim Rees)
Organization: University of Michigan IFS Project
Lines: 25

In article <9003131922.AA15055@richter.mit.edu>,
krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) writes:
> The program which originally opens the file must open the file
> with the 1-writer-many-readers I/O stream mode in order to allow
> other processes to read the file while it is being written. This
> can be done by opening the file via the IOS calls directly rather
> than by using the standard C or Fortran file opening commands.

Actually, the option you want is ios_$unregulated_opt.  But you don't have
to resort to ios_$open to get this.  open() always uses it.

Note that the DM doesn't use this when you open a read pad, so if you want
to peek at a file that another process is writing, you will need to use a
Unix command ("tail" is a good one) instead of the DM.

You also can't have two unregulated opens on the same file from different
nodes.  This is because it would be hard for Domain/OS to keep the client
caches consistent.  There is no free lunch here.  If you want simultaneous
unregulated file access from multiple clients, you have to give up
something.  RFS gives up client caching, NFS gives up data consistency
(yikes!), and Domain/OS gives up simultaneous access.

ulkob is a dangerous power tool and shouldn't be used for looking at files
that are currently locked and being written by another process.  I don't
think the man page makes this sufficiently clear.