How determine if a file is opened by another process

Andrew Patrick andrew at calvin.doc.ca
Wed Jan 30 07:44:03 AEST 1991


In article <1488 at nixsin.UUCP> koerber.sin at nixdorf.com writes:

>I want to find out, whether any process has opened a file, of which I only
>have the filename (or the inode, and the fs). The process that might have
>opened it need not be related to mine. I want to find out whether I can
>delete the file, without creating a still existing, unref'd file, which might
>grow without me knowing which file it is. I looked through inode.h and ino.h,
>but found no pointer to this.
>
>Could anyone pls give me a hint ?. Maybe it's in a table in the kernel ?

I need to know this too!

I just got the following question from one of my users:

    I need to know if there's a standard, *safe* way for a process to
    find out if some other process (any other process on the machine)
    has a specific file open at the time of the query.

    The other process is one I have no control over, and will be writing
    the file, assuming that no-one else is interested in it.  I can't
    change this other process, but I need to know when it's done writing
    the file.  It's a report-writer, and as soon as it has closed the
    file, it'll forget about it and I can do what I have to.  But I have
    to be sure that it is done writing the file before I touch it.  Any
    ideas?

    Oh yes.  The machine is an Encore Multimax 520, running UMax V (a
    System V based UNIX-alike).  I do know about the dodge of reading
    /dev/kmem, and the Multimax has a special call to get the address of
    the inode table, to make it a little safer, but I'd like to avoid
    this.  The program which needs this info would then have to be
    setuid root, or /dev/kmem would have to be opened for general read
    access, which we want to avoid if at all possible.
 
Any ideas?  


-- 
Andrew Patrick, Ph.D.       Department of Communications, Ottawa, CANADA
andrew at calvin.doc.CA
                    "The interface IS the program."



More information about the Comp.unix.internals mailing list