From owner-freebsd-hackers Mon Mar 27 12:09:42 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA05161 for hackers-outgoing; Mon, 27 Mar 1995 12:09:42 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA05155 for ; Mon, 27 Mar 1995 12:09:41 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA02888; Mon, 27 Mar 95 10:08:44 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503271708.AA02888@cs.weber.edu> Subject: Re: lsof ported? To: gvrooij@mmra1.ms.philips.nl (Guido van Rooij) Date: Mon, 27 Mar 95 10:08:44 MST Cc: freebsd-hackers@FreeBSD.org In-Reply-To: <9503271137.AA22173@mmra1.ms.philips.nl> from "Guido van Rooij" at Mar 27, 95 01:37:43 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > There is this handy program that lists all open file descriptors > called lsof. It not only lists all open inodes but sockets as well. > > lsof used to work on 1.1 systems but with 2.0 it seems nontrivial > to port it. Hence my question. All lsof does is traverse the system open file table, on the assumption that the id's are not shared. Basically, this is the same thing identd does. The system open file table has the struct file *'s that refer to the target files, as well as the process information for the openener. Conceptually, it's a rather trivial program. I haven't looked at the newest BSD changes, but I know that on newer versions of SVR4, the system open file table is dynamically allocated, and an lsof utility would have to traverse the open file table of all active processes. Under BSD, this would be even more trivial to implement because you could use an SIUD root program and simply recursively descend in /proc. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.