mok@joplin.mpr.ca (Winston Mok) (03/10/90)
I am a novice user of the AEGIS operating system. I would like a way to subvert the file locking mechanism so that I can look at the contents of a file while it is being written. I have tried using the dm visual editor and commands such as catf and fopen in a C program. They all return file is busy type messages. Forcibly unlocking the file with ulkob -f seems to screw up writing to the file by the origial process. Thanks for any help on this matter. ****************************************************************** * Winston Mok Pacific Microelectronics Centre *
krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) (03/14/90)
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. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
rees@dabo.ifs.umich.edu (Jim Rees) (03/14/90)
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.