Re: testing for open files or volumes
Re: testing for open files or volumes
- Subject: Re: testing for open files or volumes
- From: "Justin C. Walker" <email@hidden>
- Date: Tue, 3 Dec 2002 22:49:42 -0800
On Tuesday, December 3, 2002, at 10:21 PM, Alex Reynolds wrote:
On Tuesday, December 3, 2002, at 10:55 PM, Umesh Vaishampayan wrote:
On Monday, December 2, 2002, at 10:36 PM, Alex Reynolds wrote:
I was wondering if there are ways to test whether a file is open by
another process under Darwin (and by extension Mac OS X)?
Even if these was such an API, wow do you guarantee that the answer
isn't stale by the time you get around to act on it?
I'm a little confused by the meaning of stale -- if a removable volume
can't be ejected when a file is open, wouldn't there have to be some
mechanism at the kernel or a higher level that prevents this event?
Not necessarily. I think that a usage count on each mount point inode
does the job (see the 'umount' code for any of the file systems
supported, in the xnu tree). The API you ask about is (although it
doesn't exist) a very inefficient way to determine whether the volume is
busy.
Once the file is closed, the volume must maintain some fresh
information about this because the disk can then be unmounted pretty
soon thereafter.
The unmounting operation causes all cached disk blocks to be flushed;
the "final" information regarding recently-closed files would wander out
to disk sometime between the close and the final flush.
I guess I'm looking for state information that would tell me whether a
volume has an open file, or allow me to try to lock all files one by
one (and have a lock attempt rejected if a file is locked elsewhere,
indicating a busy volume). To me, the end result would be equivalent.
Why would you want to lock all files on a volume? What are you trying
to do? The above doesn't enlighten me.
Note that it's the kernel that determines whether a file system is busy
when a request to unmount comes along. No user-mode code is involved.
There are a couple of command-line commands (fstat and lsof) that
provide information about open files per process; you could look at that
source to determine the ugliness of getting that information at user
level (and as Umesh notes, the information is likely to be stale,
depending on the activity on your system).
I suppose I'm looking for something similar to how NFS manages to
handle this issue, but none of the POSIX locking functions I've tried
seem to hand back useful errors under OS X.
I don't think that NFS worries about this; that's one of the joys of
being stateless. The client-side handles this in the same way that it
does for local volumes. The server-side doesn't care.
Regards,
Justin
--
Justin C. Walker, Curmudgeon-At-Large *
Institute for General Semantics | If you're not confused,
| You're not paying attention
*--------------------------------------*-------------------------------*
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.