Tim Cutts <timc at chiark.greenend.org.uk> wrote in message news:<OIl*9yt5o at news.chiark.greenend.org.uk>...
> ...
> Have you ever looked at the sources for lsof? :-) Most of the things
> it does are completely system-specific.
There are two clear divisions in what lsof does: 1) it gathers
open file information, something that is UNIX dialect specific;
and 2) it delivers information in a dialect-independent fashion.
Both operations are significant and I wouldn't characterize either
as most of what lsof does.
> Many of these things are
> not portable even between versions of the same OS; for example you can
> do what you want here really trivially on Linux 2.2 or later through
> /proc/$pid/fd/$fd, which is a symbolic link to the file the descriptor
> has open. Linux 2.0 and earlier just have an inode number, I think.
In Linux before 2.1.72 kernels lsof dived into the kernel memory
dumpster for information about open files. After that Linux
kernel version the /proc file system *almost* delivers enough
information -- it still doesn't deliver current file position,
a significant loss to some lsof users.
> A few years ago the author of lsof had to drop support for IRIX, because
> SGI were refusing to supply him with kernel struct details he needed.
> Don't know whether that's still the case.
IRIX is still an abandoned front for lsof. A few failed attempts
have been made to restart it, but none have produced any results.
> Sigh. UNIX can be really horrible at times, can't it? I seem to have
> opened a can of worms here. Sorry!
Let's be clear on the matter of displaying UNIX open file info.
With the exception of the L:nux 2.1.72 and above /proc file system,
and the HP-UX 11.11 PSTAT(2) PEGL upgrade, lsof is collecting
information no UNIX kernel was ever designed to deliver. I
don't think we can call UNIX terrible for that shortcoming, but
must admit that administrative expectations have risen.
Vic Abell, lsof author
