How can I find out who is on a filesystem when I can't umount it?

[Will Crowder]

In article <1991Feb28.205352.26287 at athena.mit.edu>, jik at athena.mit.edu
(Jonathan I. Kamens) writes:

|> First of all, about finding out what processes are using a filesystem -- the
|> best utility I've seen for doing that is "ofiles".  You can find out where to
|> get the source to "ofiles" by telnet'ing to quiche.cs.mcgill.ca (132.206.2.3
|> or 132.206.51.1) and logging in as "archie".  Type "help" once you get a
|> prompt to find out how to use archie.  If you don't want to do that, you can
|> just get the version of ofiles (you probably want "ofiles.new") available in
|> the comp.sources.unix archives.

The ofiles.new in the last comp.sources.unix archive I saw won't run under
SunOS 4.1.x.  This is due to the change in the user area u_ofile pointer.
Under SunOS 4.1.x, u_ofile is a pointer to either u_ofile_arr, which is
an array in the user area, or some piece of kernel-allocated memory.  This 
is to allow the number of open file descriptors to exceed the available
space for file descriptors in the u area.  (That value is #defined as
NOFILE_IN_U and under 4.1.1 is 64.)

The problem is that the kvm_getu() call used in ofiles doesn't adjust the
u_ofile pointer to point to the copy of the u_ofile_arr.  u_ofile still
points somewhere in kernel memory, and causes a SEGV when ofiles tries to
access it.  The fix is to determine if the pointer pointed somewhere in the
u area and if so, just adjust it to point to the local copy, or do a 
kvm_read() (or whatever) to read the real array into user space and then
point u_ofile at it.

|> Jonathan Kamens			              USnail:
|> MIT Project Athena				11 Ashford Terrace
|> jik at Athena.MIT.EDU				Allston, MA  02134
|> Office: 617-253-8085			      Home: 617-782-0710

Will
----
Will Crowder, INTERACTIVE Systems Corporation
willcr at ivy.isc.com