Xref: utzoo comp.unix.questions:28302 comp.unix.admin:897 comp.unix.internals:1904 comp.unix.programmer:929 comp.unix.misc:875
Newsgroups: comp.unix.questions,comp.unix.admin,comp.unix.internals,comp.unix.programmer,comp.unix.misc
Path: utzoo!utgpu!cunews!dgbt!rick.doc.ca!calvin.doc.ca!andrew
From: andrew@calvin.doc.ca (Andrew Patrick)
Subject: Re: How determine if a file is opened by another process
Message-ID: <1991Jan29.204403.6071@rick.doc.ca>
Summary: We really need to know this!
Keywords: file open
Sender: news@rick.doc.ca
Nntp-Posting-Host: calvin.doc.ca
Organization: Communications Research Centre, Ottawa
References: <1488@nixsin.UUCP>
Date: Tue, 29 Jan 1991 20:44:03 GMT

In article <1488@nixsin.UUCP> koerber.sin@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@calvin.doc.CA
                    "The interface IS the program."