Lsof is able to examine the kernel's name cache or use other
kernel facilities (e.g., the ADVFS 4.x tag_to_path() function
under Tru64 UNIX) on some dialects for most file system types,
excluding AFS, and extract recently used path name components
from it. (AFS file system path lookups don't use the kernel's
name cache; some Solaris VxFS file system operations apparently
don't use it, either.)
Lsof reports the complete paths it finds in the NAME column. If
lsof can't report all components in a path, it reports in the
NAME column the file system name, followed by a space, two `-'
characters, another space, and the name components it has
located, separated by the `/' character.
When lsof is run in repeat mode - i.e., with the -r option
specified - the extent to which it can report path name
components for the same file may vary from cycle to cycle.
That's because other running processes can cause the kernel to
remove entries from its name cache and replace them with others.
Lsof's use of the kernel name cache to identify the paths of
files can lead it to report incorrect components under some
circumstances. This can happen when the kernel name cache uses
device and node number as a key (e.g., SCO OpenServer) and a key
on a rapidly changing file system is reused. If the UNIX
dialect's kernel doesn't purge the name cache entry for a file
when it is unlinked, lsof may find a reference to the wrong entry
in the cache. The lsof FAQ (The FAQ section gives its location.)
has more information on this situation.
Lsof can report path name components for these dialects:
FreeBSD
HP-UX
Linux
NetBSD
NEXTSTEP
OpenBSD
OPENSTEP
SCO OpenServer
SCO|Caldera UnixWare
Solaris
Tru64 UNIX
Lsof can't report path name components for these dialects:
AIX
If you want to know why lsof can't report path name components
for some dialects, see the lsof FAQ (The FAQ section gives its
location.)
