Imported Upstream version 4.87upstream/4.87

95 files changed, 82438 insertions, 0 deletions

diff --git a/00.README.FIRST b/00.README.FIRST
new file mode 100644
index 0000000..ea1355c
--- /dev/null
+++ b/00.README.FIRST
@@ -0,0 +1,48 @@
+Now that you have the lsof distribution, I suggest:
+
+*  If you're unfamiliar with lsof, read 00README for information on
+   Configuring and building lsof, 00QUICKSTART for tips on using lsof.
+
+   If you're too impatient for that, do this:
+
+      $ ./Configure <put your UNIX dialect's abbreviation here>
+        (Do the inventory step, as you prefer.)
+        (Do the customization step, as you prefer.)
+      $ make
+      $ ./lsof -h
+
+   To get a list of UNIX dialect abbreviations:
+
+      $ Configure -h
+
+   Please don't be impatient -- read the documentation first.
+
+*  Read the current distribution's details in 00DIST.  (The
+   ChangeLog file points to 00DIST.)
+
+*  If you want technical details, read 00DCACHE and 00PORTING.
+
+*  If you want to cross-configure, read 00XCONFIG.
+
+*  Use the test suite, described in 00TEST, by:
+
+	$ cd tests
+	$ make
+
+   and possibly:
+
+	$ make opt
+
+*  If you're having trouble, read 00FAQ.  (Please read 00FAQ before
+   you send a bug report.)
+
+*  Lsof contributors may find their names in 00CREDITS.  (Thanks, again.)
+
+*  Read the lsof.man page file.  Its nroff source is in lsof.8.
+
+*  Consider subscribing to the lsof-l mailing list -- read 00LSOF-L
+   for details.
+
+
+Vic Abell <abe@purdue.edu>
+January 2, 2013
diff --git a/00.README.FIRST_4.87 b/00.README.FIRST_4.87
new file mode 100644
index 0000000..14e0b17
--- /dev/null
+++ b/00.README.FIRST_4.87
@@ -0,0 +1,29 @@
+A tour of the lsof_4.87 distribution:
+
+  00.README.FIRST_4.87 is this file.
+
+  README.lsof_4.87 contains distribution and security information.
+
+  RELEASE.SUMMARY_4.87 contains a summary of the lsof 4.87
+  distribution.
+
+  lsof_4.87_src.tar is the lsof 4.87 source tar archive.
+
+  lsof_4.87_src.tar.sig is a detached GPG certificate for
+  lsof_4.87_src.tar.
+
+I suggest you follow these steps:
+
+1.  Read 00.README.FIRST_4.87.
+
+2.  Read README.lsof_4.87 and follow its instructions to verify
+    the authenticity of lsof_4.87_src.tar.
+
+3.  Unpack lsof_4.87_src.tar -- use `tar xf lsof_4.87_src.tar`.
+    That will produce an lsof_4.87_src sub-directory.
+
+4.  Change to the lsof_4.87_src sub-directory and read its
+    00.README.FIRST file.
+
+Vic Abell <abe@purdue.edu>
+Wed Jan 2 12:52:08 EST 2013
diff --git a/00CREDITS b/00CREDITS
new file mode 100644
index 0000000..9c7688a
--- /dev/null
+++ b/00CREDITS
@@ -0,0 +1,533 @@
+
+			    Lsof Credits
+
+I owe an enormous debt to the users of lsof who have contributed
+to its steady growth.  The size of the list of people who have
+helped me, while it has grown too large to include in the lsof man
+page any more, is a testimonial to their generosity.
+
+First I acknowledge a debt to the work of Dan Bernstein, Michael
+``Ford'' Ditto, Tom Dunigan, Alexander Dupuy, Vik Lall, Ray Moody,
+C. Spencer, Michael Spitzer and those who wrote Berkeley's fstat
+program, all contributors to lsof's predecessors.
+
+I thank Doug McKenzie for his HP-UX proctor program and Rich Kulawiec
+for pointing it out.
+
+Finally I thank all the following people who have used lsof, pointed
+out its flaws, described its shortcomings, offered suggestions for
+improving it, supplied code for it, gave me technical advice, and
+provided test systems where I was able to do development work.
+
+	Szilveszter Adam
+	David Addison
+	Elias Halldor Agustsson
+	Per Allansson
+	Jim Ankenbrandt
+	Richard Allen
+	Thomas Anders
+	Ric Anderson
+	Stuart Anderson
+	Michael Antlitz
+	Marc Auslander
+	Tigran Aivazian
+	Jos Backus
+	David Bacon
+	Alexis Ballier
+	Scott Ballew
+	Ade Barkah
+	Alon Bar-Lev
+	Brett Bartick
+	Anthony Baxter
+	John Beacom
+	Bruce Beare
+	M. Jay Beck
+	Marek Behun
+	Bill Behr
+	Michael Beirne
+	Marc Bejarano
+	Andrew Bell
+	Steve Bellenot
+	Robert Benites
+	Dmitry Berezin
+	Ulrich Bernhard
+	Peter J. Bertoncini
+	Dave Bianchi
+	Mark Bixby
+	Allan Black
+	Jan Blunck
+	Achim Bohnet
+	Steve Bonds
+	Mark Bonsack
+	Volker Borchert
+	Bill Bormann
+	Ermin Borovac
+	Heddy Boubaker
+	Pieter Bowman
+	Michael Bracewell
+	H. Merijn Brand
+	Danny Braniss
+	Thomas Braunbeck
+	Kieran Broadfoot
+	Dean Brock
+	Hal Brooks
+	Andrew Brown
+	Jim Brown
+	Michael Bryan
+	Matthew Burt
+	Robert Byrnes
+	Pierfrancesco Caci
+	Bill Campbell
+	David Capshaw
+	John Caruso
+	Jon Champlin
+	Kris Chandrasekhar
+	Albert Chin-A-Young
+	Bernt Christandl
+	Marc Christensen
+	Hans Petter Christiansen
+	Tom Christiansen
+	Yves Christophe
+	Richard Chycoski
+	A. Channing Clark
+	Axel Clauberg
+	John Clear
+	David Clissold
+	Richard Coley
+	John Colgrave
+	David Comay
+	Lionel Cons
+	Bob Cook
+	Patrick Connor
+	Carl Cook
+	Jim Cooper
+	Roger Cornelius
+	Doug Crabill
+	Eric Cronin
+	Kim Culhan
+	Dave Curry
+	Robert Dahlem
+	Guy Dallaire
+	D. Chris Daniels
+	Renata Maria Dart
+	Ian Darwin
+	Carl E. Davidson
+	David Day
+	Will Day
+	Frederic Delanoy
+	Mike Depot
+	Steve Dibbell
+	Hugh Dickins
+	David DiGiacomo
+	Casper Dik
+	John DiMarco
+	Don Draper
+	Michel Dubois
+	Eric Dumazet
+	Dick Dunbar
+	Marc Duponcheel
+	Jan Dvorak
+	Calle Dybedahl
+	John Dzubera
+	Jeff Earickson
+	Greg Earle
+	Bernd Eckenfels
+	Niklas Edmundsson
+	Philip Edwards
+	Robert Ehrlich
+	Mark W. Eichin
+	Doug Eldred
+	Scott Ellentuch
+	Tom Endo
+	Grant Erickson
+	Craig Everhart
+	Chris Evert
+	Bob Farmer
+	Sami Farin
+	Mike Feldman
+	Quentin Fennessy
+	Ian Fitchet
+	Toralf Foerster
+	Bob Foertsch
+	Pierre-Yves Fontaniere
+	Ralph Forsythe
+	Jason Fortezzo
+	Mike Fraser
+	Curt Freeland
+	Terry Friedrichsen
+	Mike Frysinger
+	Harvey Garner
+	Carson Gaspar
+	Stuart D. Gathman
+	Brian L. Gentry
+	Dave Gilbert
+	Steve Ginsberg
+	Edwin Groothuis
+	Jin Guojun
+	Kurt Gollhardt
+	Roman Gollent
+	Steve Gonczi
+	Bill Goodridge
+	Julian Gordon
+	Marcin Gozdalik
+	Henry Grebler
+	Richard Green
+	Chaskiel Grundman
+	Armin Gruner
+	David Gutierrez
+	Robert Hall
+	Garner Halloran
+	Adam Hammer
+	Charles Hannum
+	Vlad Harchev
+	Craig Harmer
+	Michael Haro
+	Peter Harvey
+	Steinar Haug
+	Jia He
+	Sheldon Hearn
+	John Heasley
+	Wolfgang Hecht
+	Janet Hempstead
+	Michael Hennecke
+	Randolph J. Herber
+	Andrew Hill
+	Kurt Hillig
+	Steven Hinkle
+	Paul Hite
+	Billy Ho
+	Michael Hocke
+	Brett Hogden
+	Gaylord Holder
+	Kjetil Torgrim Homme
+	Pekka Honkanen
+	Jeffrey C. Honig
+	Heidi Hornstein
+	Michael A. Hovan III
+	Barbara Howe
+	J. Nelson Howell
+	Jeff Howie
+	Louis Huemiller
+	John Hughes
+	Gerrit Huizenga
+	Peter Ilieve
+	Mayer Ilovitz
+	Gregory A. Ivanov
+	John Jackson
+	Kurt Jaeger
+	Edward Jajko
+	Marian Jancar
+	Paul Jarc
+	Jakub Jelinek
+	Robert Jelinek
+	Bruce Jerrick
+	Carl Johnson
+	Dion Johnson
+	Jeff Johnson
+	Douglas B. Jones
+	LaMont Jones
+	Peter Jordan
+	Arne H. Juul
+	Pasi Kaara
+	Frank Kaefer
+	Keith Kalet
+	Claus Kalle
+	Henri Karrenbeld
+	Amir Katz
+	Henry Katz
+	Kawaljeet Kaur
+	Doug Kehn
+	Kris Kennaway
+	Terry Kennedy
+	Shane Kenney
+	Andrew Kephart
+	Robert Kiessling
+	Joshua Kinard
+	Don Kirouac
+	Steve Kirsch
+	Philip Kizer
+	Thomas Klausner
+	Roger Klorese
+	Peter Klosky
+	Przemek Klosowski
+	Angelos D. Keromytis
+	Radko Keves
+	Valdis Kletnieks
+	Chris Kordish
+	Alek O. Komarnitsky
+	Joseph Kowalski
+	Christian Krackowizer
+	Paul Kranenburg
+	Troyan Krastev
+	Brad Krebs
+	Alex Kreis
+	Johannes Kroeger
+	Vincent Kujala
+	Ken Laing
+	Shirley Lam
+	Erwin Lansing
+	Victoria H. Lau
+	Markus Lautenbacher
+	Steve Lacey
+	Marc Aurele La France
+	Chad R. Larson
+	Steve Laubscher
+	Andrei V. Lavreniyuk
+	Loc Le
+	Tin Le
+	Diane Lebel
+	Francis Le Bourse
+	Kyungjoon Lee
+	Marty Leisner
+	Maciej Lesniewski
+	Stuart Levy
+	Ben Lewis
+	Michael Lewis
+	Angel Li
+	Ambrose Li
+	Wendy Lin
+	Carl E. Lindberg
+	Onno van der Linden
+	Johan Lindquist
+	James Lingard
+	Jason Lingohr
+	Robert Lipe
+	Gabor Liptak
+	Friedel Loinger
+	Michael Long
+	Pete Lord
+	Steve Logue
+	Bela Lubkin
+	Pav Lucistnik
+	Horst Luehrsen
+	Andreas Luik
+	Timothy J. Luoma
+	Michael Mackenzie
+	Lawrence MacIntyre
+	Jerome Marchand
+	Benson Margulies
+	Claude Marinier
+	Chris Markle
+	Roy Marples
+	Eberhard Mater
+	James Mathiesen
+	Tom Matthews
+	Fletcher Mattox
+	David Mazieres
+	Brian McAllister
+	Scott McClung
+	Dale McCluskey
+	Terry McCoy
+	Sean McDermott
+	Duncan McEwan
+	Dwight McKay
+	William McVey
+	Eric McWhorter
+	Marjo F. Mercado
+	Dan Mercer
+	Bill Melvin
+	Andrew Merril
+	Richard van Meurs
+	Jim Mewes
+	Gary Millen
+	Timothy Miller
+	Davin Milun
+	Yuliy Minchev
+	Jim Mintha
+	Mike Miscevic
+	Arkadiusz Miskiewicz
+	Janardhan Molumuri
+	Nasser Momtaheni
+	Laurent Montaron
+	Phillip Moore
+	Dmitry Morozovsky
+	John Paul Morrison
+	John Gardiner Myers
+	Jeffrey Mogul
+	Dave Morrison
+	Pat Myrto
+	Toshiya Nakamura
+	Filippo Natali
+	Allan Nathanson
+	Chance Neale
+	Dan Nelson
+	Vladislav Nespor
+	Bjorn S. Nilsson
+	Anders Nordby
+	Joseph J. Nuspl Jr.
+	David O'Brien
+	Alexandre Oliva
+	Craig B. Olofson
+	Dave Olson
+	Rainer Orth
+	Sergey A. Osokin
+	Keith Parks
+	Will Partain
+	Vasco Pedro
+	Mark Peek
+	Ezra Peisach
+	Bill Pemberton
+	Lee Penn
+	Gildas Perrot
+	Jesse Perry
+	Nathan Peterson
+	Dominique Petitpierre
+	Hung Pham
+	Ray Phillips
+	Francois Pinard
+	Alex Podlecki
+	Lutz Poetschulat,
+	John Polstra
+	Scott Presnell
+	Mark Price
+	Philippe-Andre Prindeville
+	David Putz
+	Tom Qin
+	Kurtis Rader
+	Peter Radig
+	Jean-Pierre Radley
+	Tim Ramsey
+	Dewan Rashid
+	Richard J. Rauenzahn
+	Louis Rayman
+	Brian Redman
+	Eric S. Raymond
+	Erwin Reyns
+	Aaron Rhodes
+	Jim Reid
+	Jean-Luc Richier
+	Clint Roberts
+	Ingimar Robertson
+	Sylvain Robitaille
+	Larry Rogers
+	Malgorzata Roos
+	Larry Rosenman
+	Stephan Rossi
+	Kevin Ruderman
+	Wolfgang Rupprecht
+	Pavol Rusnak
+	Conrad J. Sabatier
+	Klaus Saggerer
+	Chris Schanzle
+	Igor Schein
+	Horst Scheuermann
+	Peter Schiffer
+	Michael Schmitz
+	Larry Schwimmer
+	Hendrik G. Seliger
+	Igor V. Semenyuk
+	Jonathan Sergent
+	Frank Sanders
+	Berkley Shands
+	Gregory Neil Shapiro
+	Eyal Shaynis
+	Michael Shields
+	Wesley Shields
+	Philip Shin
+	Anthony Shortland
+	Dave Sill
+	John Silva
+	Chuck Silvers
+	Gerry Singleton
+	Leonard Sitongia
+	Kevin Smallwood
+	Curt Smith
+	Ben Smithurst
+	Douglas R. Smith
+	Kevin Smith
+	Chang Song
+	Josh Soref
+	John Speno
+	Kenneth Stailey
+	Piet Starreveld
+	David Steiner
+	Charles Stephens
+	Marc Stephenson
+	Chip Stettler
+	Dave Stevens
+	Jeff Stewart
+	Diana Stockdale
+	Andreas Stolcke
+	Jeff Stoner
+	Sushila Subramanian
+	Jan Ole Suhr
+	Mike Sullivan
+	Patrick D. Sullivan
+	Peter Svensson
+	Chris Sylvain
+	Miklos Szeredi
+	Paul Szabo
+	Dale Talcott
+	Jon A. Tankersley
+	Jan Tax
+	Samuel Thibault
+	Andy Thomas
+	Matthew Thurmaier
+	Chris Timmons
+	Andrzej Tobola
+	R. Lindsay Todd
+	Zdenko Tomasic
+	Michael Townsend
+	Linus Torvalds
+	Mike Tracy
+	Jeff Trawick
+	Dan Trinkle
+	Erik Trulsson
+	Lars Tunkrans
+	Lenny Turetsky
+	Kevin Vajk
+	Peter Valchev
+	John R. Vanderpool
+	Peter Van Epp
+	Peter C. Vernam
+	Peter Vines
+	Bob Ward
+	Jules van Weerden
+	Tom Weaver
+	Fernando A.B. Whitaker
+	Tom Whitty
+	Carson Wilson
+	David J. Wilson
+	Frank Winkler
+	Marc Winkler
+	Mark Vasoll
+	Holger VanKoll
+	Robert Vernon
+	Joep Vesseur
+	Larry Virden
+	Jos Vos
+	Jun Biao Wang
+	Christopher J Warweg
+	Bill Watson
+	Florian M. Weps
+	Joel White
+	Paul Wickman
+	Martin Wilke
+	Eric Williams
+	Steve Williams
+	Steve Wilson
+	Erich Wimmer
+	Wally Winzer, Jr.
+	Patrick Wolfe
+	Stephen Woods
+	James Woodward
+	Scott Worley
+	Jan Wortelboer
+	Joshua Wright
+	Sailu Yallapragada
+	Masatake YAMATO
+	Donna Yobs
+	Ron Young
+	Warren Young
+	Blair Zajac
+	Karel Zak
+	Donald Zoch
+	Malcom Zung
+	and Waldemar Zurowski
+
+If I have omitted a contributor's name, the fault is wholly mine,
+and I apologize for the error.
+
+
+Vic Abell <abe@purdue.edu>
+January 2, 2013
diff --git a/00DCACHE b/00DCACHE
new file mode 100644
index 0000000..58747b2
--- /dev/null
+++ b/00DCACHE
@@ -0,0 +1,745 @@
+
+    	Configuring The Device Cache File Path
+
+			    Contents
+
+		A.  Introduction and History
+		B.  Device Cache File Format
+		    1.	Integrity Checks
+		    2.	The Setgid and Setuid-root States
+		C. Device Cache File Path Options
+		    1.	Path Named by ``-D''
+		    2.	Path Named in Environment Variable
+		    3.	Default System-wide Path
+			a.  Build Procedure
+		    4.	Default Personal Path
+		    5.	Modified Default Personal Path
+		D. Displaying the Default Path
+		Appendix A, Unix Dialects Without a Device Cache
+		Appendix B, Lsof Dialects and Their Permissions
+		    1.	Setuid-root Lsof Dialects 
+		    2.	Setgid Lsof Dialects That Surrender Setgid
+		   	Permission
+
+
+A. Introduction and History
+===========================
+
+Lsof writes a file of information about the contents of the nodes
+in /dev (or /devices) to reduce its startup overhead on later calls.
+It does this for all Unix dialects, except those noted in Appendix A.
+
+This file, called the device cache file, enables lsof to avoid
+calling the kernel stat(2) function on every node in /dev (or
+/devices) from which it builds a table of correspondence between
+major/minor device numbers and device names.
+
+A full scan of /dev (or /devices) on some systems may involve
+calling the sometimes-slow stat(2) function 10,000 times or more.
+Furthermore, each stat(2) call consumes space in the kernel's name
+cache, forcing from it path name components that would be more
+useful when lsof tries to associate them with open files.
+
+While it's hard to question the usefulness of the device cache,
+it's also hard to decide where it should be written.  When the
+feature was first added, the device cache file was written to /tmp,
+and its ownership was set to that of the real user ID (UID) under
+which the creating lsof process was run.  However, to enable any
+process to update it when /dev (or /devices) changed, lsof set its
+modes to 0666, thus allowing anyone to read or write it.
+
+The writing of a world-readable and world-writable device cache
+file to any place has security weaknesses.  A clever intruder who
+carefully preserves the integrity of the file might be able to
+remove devices that would prevent lsof from observing the intruder's
+files.  A clever intruder might also be able to put a symbolic link
+in place and trick lsof into writing to the link's destination with
+its effective permissions, thus bypassing the real user's (possibly
+weaker) permissions.
+
+Later the location of the device cache file was changed.  It was
+converted to a personal file, located in the home directory of each
+real UID that executed lsof, and owned by that UID.  Thus it was
+no longer possible for one user to affect lsof's access to the
+device cache file, nor was it possible for a user to mount a symbolic
+link attack on a restricted file, but the result was that each lsof
+user had a private copy of the device cache file.
+
+The device cache file feature has undergone some further refinements
+in path name formation to reach its present state.  This documentation
+describes the path name formation options open to the lsof builder
+and user after those refinements, and how lsof attempts to insure
+that none of the options presents a security risk.
+
+
+B. Device Cache File Format
+===========================
+
+The device cache file is a flat file of ASCII text.  It has an
+initial statement of how many sections the file might contain --
+the possible sections are character devices, block devices, clone
+devices, pseudo devices, and checksum.  The character devices and
+checksum sections are always present.
+
+Each section has a header that numbers the entries in the section.
+
+The last section is a checksum section that contains a 16 bit cyclic
+redundancy (CRC) checksum of everything in the file but the checksum
+section itself.
+
+Lsof always sets the permission modes of the device cache file to
+0600, and the owner to the real UID of the process that executes
+lsof; the group, the real group ID (GID) of the lsof process.
+
+Setting the permission modes to 0600 means that a system-wide device
+cache file won't be usable unless the procedure that builds it
+changes the modes after lsof has written it.  A suitable procedure
+for building a system-wide device cache that shows how to adjust
+these inadequate permission modes is given in the Default System-wide
+Path section.
+
+
+B.1. Integrity Checks
+=====================
+
+When lsof opens the device cache file it makes these integrity
+checks:
+
+    1.  Lsof must gain permission from access(2) to be able to
+	open the file for reading.  If lsof is writing the file,
+	it usually cedes permission control to the applicable
+	directory and file modes and ownerships.  (Some additional
+	checks apply and they're described in the sections on path
+	options.)
+
+	By explicit design lsof never writes to the system-wide
+	device cache file, even when the real UID of its process
+	is root.  The system-wide device cache file must be written
+	with a root-owned procedure via the ``-D[b|u<path>'' options
+	-- i.e., under the system administrator's control.  (See
+	the Build Procedure sub-section of the Default System-wide
+	Path section.)
+
+    2.  The device cache file's modes must be 0600 (0644 if lsof
+	is reading a system-wide device cache file) and its size
+	must be non-zero.
+
+    3.  There must be a correctly formatted section count line
+	at the beginning of the file.
+
+    4.  Each section must have a header line with a count that
+	properly numbers the lines in the section.  The first words
+	of legal section titles are "device", "block", "clone",
+	"pseudo", and "CRC".
+
+    5.  The lines of a section must have the proper format.
+
+    6.  All lines are included in a 16 bit CRC, and it is recorded
+	in a non-checksummed section line at the end of the file.
+
+    7.  The checksum computed when the file is read must match the
+	checksum recorded when the file was written.
+
+    8.  The checksum section line must be followed by end-of-
+	information.
+
+    9.  Lsof must be able to get matching results from stat(2)
+	on a randomly chosen entry of the device section.
+
+
+B.2. The Setgid and Setuid-root States
+======================================
+
+There are two fundamental ways in which lsof is granted access to
+restricted system resources.  Both access methods are related to the
+effective permissions given the lsof binary or executable.
+
+The first and preferable way to grant lsof access to system resources
+through the permissions endowed on its executable is the giving of
+set group ID (setgid) permission.  The group is the one that has
+permission to read the kernel memory and swap devices -- e.g., /dev/kmem,
+/dev/mem, /dev/swap, etc.
+
+This method of granting access is called setgid mode because it
+enables lsof to run with an effective group ID set to the one
+granted by the permissions of its executable file and by the group
+that owns the executable file.  See the getegid(2) man page for a
+further discussion of effective group ID.
+
+Usually lsof only needs setgid permission to open access to the
+kernel memory files.  After they're open, lsof drops its setgid
+permission.
+
+The second and least preferable way to grant lsof access to system
+resources through the permissions endowed on its executable is the
+giving of set user ID to root (setuid-root) permission.  This is
+much too strong a permission, but necessary: to use the -X option
+fully for the version of lsof for AIX 5 and above; to use the
+version of lsof for HP-UX 11.11 and above; and to use the version
+of lsof for Linux 2.1.72 and above.  These lsof implementations
+require setuid-root permission to be able to access restricted
+resources -- e.g., the individual files of the /proc file system.
+(But note that the setuid-root Linux lsof doesn't need and has no
+device cache support.)
+
+Lsof never drops setuid-root permission, because it needs that
+power throughout its execution.  However, when the lsof process is
+setuid-root, lsof disallows these device cache file path options:
+
+    1.  It ignores the ``-D[b|r|u]<path>'' options.  It accepts
+        only the ``-Di'' and ``-Dr'' options.
+
+    2.	It refuses to recognize a path supplied via an environment
+	variable.
+
+    3.  It refuses to accept an additional path component from an
+	environment variable to be inserted in the middle of a
+	personal device cache file path.
+
+Each restriction is imposed because setuid-root power might allow
+a malicious user to form a device cache file path that would give
+read access to a normally inaccessible place (That's bad enough.),
+or write access to a critical system file (That's the worst case.)
+
+There is one further state that lsof can enter that is slightly
+different from the setuid-root and setgid states.  That state occurs
+when lsof is being run from a root shell -- i.e., the lsof real
+user ID is root.  To avoid accidental complications, when lsof is
+in this state, it ignores all environment variable options.
+
+In the rest of this document you will find more detailed discussion
+of the special restrictions caused by the type of permission that
+has been given the lsof executable.
+
+
+C. Device Cache File Path Options
+=================================
+
+Lsof offers five options for constructing the path to the device
+cache file.  Each has special conditions and safeguards that
+surround its use.  The options are:
+
+    1.	A device cache file that is named in the <path> component
+	of the parameters of lsof's ``-D'' option.
+
+	=========================================================
+	* This is a default option of the lsof distribution.	*
+	*							*
+	* Paths specified with this option are read-only unless	*
+	* the real UID of the lsof process is root (0), or the	*
+	* lsof process is able to surrender setgid permission	*
+	* (See Appendix B) and it is not setuid-root.		*
+	=========================================================
+
+    2.	A device cache file whose name is specified by an environment
+	variable.
+
+	=========================================================
+	* This is a default option of the lsof distribution.	*
+	*							*
+	* This option is enabled when the lsof dialect is able	*
+	* to surrender setgid permission (See Appendix B.), and	* 
+	* the lsof process is not setuid-root.			*
+	*							*
+	* The environment variable path is read-only if the	*
+	* lsof process does not surrender setgid permission	*
+	* (See Appendix B.)					*
+	=========================================================
+
+    3.	A system-wide default device cache file, located at a path
+	determined by the builder of lsof.  The lsof builder is also
+	responsible for building the device cache file, using a
+	different lsof path formation option at a suitable time --
+	e.g., when the system is booted.
+
+	=========================================================
+	* This is option is disabled by default in the lsof	*
+	* distribution.						*
+	*							*
+	* The path specified with this option is read-only.	*
+	=========================================================
+
+    4.	A default personal device cache file, located in the UID's
+	home directory.
+
+	=========================================================
+	* This is a default option of the lsof distribution.	*
+	=========================================================
+
+    5.	A personal device cache file whose name is modified by an
+	environment variable.
+
+	=========================================================
+	* This is a default option of the lsof distribution.	*
+	*							*
+	* The modified personal path is read-only if the lsof	*
+	* process does not surrender setgid permission.		*
+	*							*
+	* This option is disabled when the lsof process is	*
+	* setuid-root or its real UID is root (0).	   	*
+	=========================================================
+
+When there are multiple choices for the device cache file path,
+lsof chooses from the above list in the order the list is given,
+subject to restrictions based on the effective group and user IDs
+that are in effect.
+
+Each possible path name is discussed in a later section that
+describes the restrictions that apply to it and the method for
+building lsof to use it.
+
+In one special case lsof will use two paths in order.  When a
+system-wide device cache file is enabled, and lsof finds that it
+doesn't exist, lsof will attempt to use a personal device cache
+file.
+
+
+C.1. Path Named by ``-D''
+=========================
+
+The ``-D[b|r|u]<path>'' option can name a path for the device cache
+file where it is unconditionally built (`b'); read, but never
+rebuilt (`r'); and read and rebuilt, if necessary (`u').
+
+If the lsof process is setuid-root, no path may be specified with
+the ``-D'' option -- i.e., only the `i' function is accepted.  The
+`r' option may be used if it doesn't have a path argument.
+
+If the lsof process is not setuid-root, nor is the real UID of the
+lsof process root, a path may accompany the `b', `r', and `u'
+functions if the lsof process surrenders setgid permission.  (See
+Appendix B.)  If the process doesn't surrender setgid permission,
+then a path may accompany only `r'.
+
+Lsof's permission to access a device cache file at a path specified
+with ``-D[b|r|u]<path>'' depends completely on the permission modes
+and ownerships of the file and its directory components.
+
+When the real UID of the lsof process is root (0), paths may be
+specified with ``-D[b|r|u]''.
+
+====================================================================
+*								   *
+* The ``-D[b|r|u]<path>'' option is enabled by default in the lsof *
+* distribution by the following definition in the dialect's	   *
+* machine.h header file:					   *
+*								   *
+*	#define HASDCACHE 1					   *
+*								   *
+* To disable all device cache file options, including all ``-D''   *
+* forms, change the above line in the dialect's machine.h file to: *
+*								   *
+*	/* #define HASDCACHE 1 */				   *
+*								   *
+* or remove it.							   *
+*								   *
+* The ``-D[b|r|u]<path>'' options are disabled when the lsof	   *
+* process is setuid-root.  If the lsof process isn't setuid-root,  *
+* nor is its real UID root (0), and if the lsof process surrenders *
+* setgid permission, ``-D[b|r|u]'' may be accompanied by a path.   *
+*								   *
+* A path may accompany ``-D[b|u]'' when the real UID of the lsof   *
+* process is root.						   *
+*								   *
+* ``-Dr'' without a path name argument is always acceptable.	   *
+*								   *
+====================================================================
+
+
+C.2. Path Named in Environment Variable
+=======================================
+
+A device cache file path may be declared in an environment variable.
+This option is defined in the dialect's machine.h header file with
+the HASENVDC definition.  The value of the HASENVDC definition is
+the environment variable's name.
+
+Lsof will use the value of the environment variable named by HASENVDC
+for the device cache file path unless either of the following
+conditions apply:
+
+    1.	The lsof process is in the setuid-root state.
+or
+    2.	The effective and real UIDs of the lsof process are root
+	(0).
+
+Lsof uses the value of the HASENVDC environment variable as the
+device cache file path after it senses there is no path declared by
+a ``-D'' option.
+
+A path from an environment variable is read-only unless the lsof
+process surrenders setgid permission.  (See Appendix B.)
+
+====================================================================
+*								   *
+* The path name environment variable option is enabled by default, *
+* and the environment variable is named LSOFDEVCACHE in the lsof   *
+* distribution by the following definition in the dialect's	   *
+* machine.h header file:					   *
+*								   *
+*	#define HASENVDC "LSOFDEVCACHE"				   *
+*								   *
+* To disable the path name environment variable option, change	   *
+* the above line in the dialect's machine.h header file to:	   *
+*								   *
+*	/* #define HASENVDC "LSOFDEVCACHE" */			   *
+*								   *
+* or remove it.  To change the name of the environment variable,   *
+* change the quoted value of the HASENVDC definition -- e.g., this *
+* form changes the environment variable name to "FOOBAR":	   *
+*								   *
+*	#define HASENVDC "FOOBAR"				   *
+*								   *
+* You can disable the path name environment option by disabling	   *
+* all device cache file processing when you remove or by disabling *
+* the HASDCACHE definition in the dialect's machine.h header file. *
+*								   *
+* The path name environment option is disabled when the lsof	   *
+* process is setuid-root or when the real UID of the lsof process  *
+* is root (0).							   *
+*								   *
+* The path named in an environment variable is read-only unless    *
+* the lsof process surrenders setgid permission.  (See Appendix    *
+* B.)								   *
+*								   *
+====================================================================
+
+
+C.3. Default System-wide Path
+=============================
+
+When a default system-wide device cache file path is defined (It's
+not enabled by default in the lsof distribution.), lsof will use
+it after it discovers no path has been specified by a ``-D'' option
+and no path has been specified in the environment variable named
+in the string #define HASENVDC of the dialect's machine.h header
+file.
+
+Lsof must be able to open the system-wide device cache file --
+i.e., it must have read access to the file and search access to
+the directories that lead it.  As part of its integrity checks,
+lsof requires that the system-wide device cache file's permission
+modes be 0644.
+
+When lsof discovers that the named system-wide device cache file
+doesn't exist, it will attempt to open a personal device cache file
+should that path formation option be enabled.  This is the *only*
+case where lsof will attempt to use two device cache file paths.
+
+The system-wide device cache file is read-only; lsof will never
+attempt to write to it.  However, when the real UID of the lsof
+process is root, that process may name the system-wide device
+cache file with ``-D[b|u]<path>''.
+
+====================================================================
+*								   *
+* The system-wide file path option is disabled by default in the   *
+* lsof distribution.  This place-marking definition in a dialect's *
+* machine.h header file may be altered to enable a system-wide	   *
+* device cache file path:					   *
+*								   *
+*	/* #define HASSYSDC "/your/choice/of/path" */		   *
+*								   *
+* To enable the system-wide name option, declaring that its path   *
+* is ``/foo/bar/lsof.dc'', change the above line in the dialect's   *
+* machine.h header file to:					   *
+*								   *
+*	#define HASSYSDC "/foo/bar/lsof.dc"			   *
+*								   *
+* or change the quoted string of the definition to the path of	   *
+* your choice.							   *
+*								   *
+* You can disable the path name environment option by disabling	   *
+* all device cache file processing when you remove or disable the  *
+* HASDCACHE definition in the dialect's machine.h header file.	   *
+*								   *
+* The system-wide device cache file is read-only.		   *
+*								   *
+====================================================================
+
+
+C.3.a. Build Procedure
+======================
+
+The system administrator must build the system-wide device cache
+file at an appropriate time -- e.g., each time the system is booted,
+and each time a node is added, deleted or modified in /dev (or
+/devices).  The procedure that builds the system-wide device cache
+file must use lsof's ``-D[b|u]<path>'' options to build the file,
+and must change the file's permission modes to 0644 after it has
+been built.
+
+Here's a simple shell script procedure to build a system-wide device
+cache file.  It assumes:
+
+    1.  The Unix dialect's kernel supports the interpreter script
+	execution option -- i.e., a script whose first line has
+	the form ``#!<path_to_interpreter>''.
+    
+    2.	The chmod, echo, rm, sh, and test programs are located
+	in ``/bin''. 
+
+    3.	The string value of the HASSYSDC definition in the dialect's
+	machine.h header file is the path ``/your/choice/of/path''.
+
+    4.	The lsof executable is located in ``/usr/local/etc''.
+
+	#!/bin/sh
+	#
+	# Simple script to build a system-wide device cache file
+	# for lsof.
+
+	HASSYSDC=/your/choice/of/path
+	/bin/rm -f $HASSYSDC
+	/usr/local/etc/lsof -Du$HASSYSDC > /dev/null 2>&1
+	if /bin/test $? -ne 0
+	then
+		/bin/echo "WARNING: failed to create $HASSYSDC"
+		exit 1
+	fi
+	/bin/chmod 0644 $HASSYSDC
+	exit 0
+
+The invocation of lsof uses the ``-Du$HASSYSDC'' option to read
+the device cache file and recreate it if necessary.  The invocation
+can be made more efficient if a known process PID -- e.g., ``-p1''
+-- can be specified.  However, if that PID is not always active
+when lsof is called, lsof might set its exit code non-zero, causing
+the subsequent test to believe that the lsof call failed.  When in
+doubt, omit the PID specification and accept the extra lsof processing
+time for reporting and discarding all open file information.
+
+
+C.4. Default Personal Path
+==========================
+
+The default personal path option is defined by default in the lsof
+distribution.  The path is formed of the home directory of the real
+UID of the lsof process, followed optionally by the contents of
+the HASPERSDCPATH environment variable, followed by ``.lsof_'',
+followed by the first component (characters up to the first period)
+of the name returned by gethostname(2).
+
+If gethostname(2) returns nothing, then nothing will follow the
+``.lsof_'' string.  If the first character of what gethostname(2)
+returns is a `.', then all the gethostname(2) value will follow
+the ``/lsof_'' string.  (See the ``%l'' conversion for a way to
+make lsof include the entire host name in the path.)
+
+====================================================================
+*								   *
+* The personal path option is enabled by default in the lsof	   *
+* distribution.  The HASPERSDC #define in a dialect's machine.h	   *
+* header is a format specification that tells lsof how to form the *
+* personal device cache file path.  The conversions in the format  *
+* specification begin with `%' , ala the printf(3) function of the *
+* standard I/O library.  These conversions are supported:	   *
+*								   *
+*	``%%''	causes a single `%' to appear in the path.	   *
+*								   *
+*	``%0''	is a separator that marks the beginning of a path  *
+*		for a setuid-root lsof process or one whose real   *
+*		UID is 0.  When lsof reaches this conversion and   *
+*		the process is setuid-root or has a real UID of    *
+*		root, it erases any previously formed path and	   *
+*		restarts with the next HASPERSDC format character. *
+*		If lsof reaches this conversion and the process is *
+*		not setuid-root and its real UID is not root, path *
+*		formation is ended.				   *
+*								   *
+*	``%h''	causes the home directory of the real UID of the   *
+*		lsof process to appear in the path.		   *
+*								   *
+*	``%l''	causes the full name returned by gethostname(2) to *
+*		appear in the path.				   *
+*								   * 
+*	``%L''	causes the first component of the name returned by *
+*		gethostname(2) to appear in the path.  The first   *
+*		component is defined to be what appears to the	   *
+*		left of the first `.'.  If nothing appears to the  *
+*		left then everything will appear in the path.	   *
+*								   *
+*	``%p''	causes the value of (HASPERSDCPATH) from the	   *
+*		process environment to appear in the path.  If the *
+*		(HASPERSDCPATH) value doesn't end in a '/', one	   *
+*		will be added.					   *
+*								   *
+*	``%u''	causes the login name associated with the real UID *
+*		of the lsof process to appear in the path.	   *
+*								   *
+*	``%U''	causes the real UID of the lsof process, converted *
+*		to a decimal string, to appear in the path.	   *
+*								   *
+*	All other characters are copied from the format to the	   *
+*	path.  CAUTION: THINK VERY CAREFULLY ABOUT THE EFFECT OF   *
+*	USING CHARACTERS THAT FORM AN ABSOLUTE COMPONENT LIKE	   *
+*	``/tmp'' IN THE FORMAT.  Consider what power your dialect  *
+*	might have (e.g., if it is setuid-root) when lsof must	   *
+*	create a device cache file at the path.  Consider using a  *
+*	``%0'' conversion to declare an alternate path for lsof    *
+*	processes that are setuid-root or whose real uid is root.  *
+*	See the "How do I put the personal device cache file in    *
+*	/tmp?" question and answer in 00FAQ for an explanation of  *
+*	this example:						   *
+*								   *
+*	    #define HASPERSDC "/tmp/.lsof_%u_%l_pers%0%h/.lsof_%L" *
+*								   *
+* This is the format specification that appears in the machine.h   *
+* header files of the lsof distribution:			   *
+*								   *
+*	#define HASPERSDC "%h/%p.lsof_%L"			   *
+*								   *
+* It causes the path to be formed from the home directory of the   *
+* real UID of the lsof process (``%h''), followed by `/', followed *
+* by the contents of the environment variable named by		   *
+* HASPERSDCPATH and a trailing `/', as needed (``%p''), followed   *
+* by the string ``.lsof_'', and terminated with the first	   *
+* component of the host's name (``%L'').			   *
+*								   *
+* To change the personal path option, change the HASPERSDC string  *
+* and recompile lsof.  To disable the personal path option, remove *
+* or disable HASPERSDC.  The personal path option is disabled when *
+* HASDCACHE is not defined.					   *
+*								   *
+====================================================================
+
+
+C.5. Modified Default Personal Path
+===================================
+
+The modified default personal path form is a special case of the
+default personal path.  In this form the value of the environment
+variable named by the HASPERSDCPATH #define is inserted in the
+personal path when the ``%p'' conversion appears in the HASPERSDC
+format specification.
+
+This allows, for example, the lsof user to move personal device
+cache files to another branch of the home directory, perhaps to a
+sub-directory where multiple device cache files may appear from
+different machines that use the same NFS- mounted home directory.
+
+The HASPERSDCPATH definition of the dialect's machine.h header file
+names the environment variable.  By default in the lsof distribution
+it is LSOFPERSDCPATH.
+
+The modified personal path component is ignored when lsof process
+is setuid-root is root, lest it be maliciously or accidentally used in
+some convoluted form to access paths the real UID cannot.  The
+modified personal path component is also ignored when the real UID
+of the lsof process is root (0), so that lsof will not accidentally
+use a personal environment value.
+
+If the lsof process surrenders setgid permission (See Appendix B.),
+lsof can read from and write to the modified personal path.  If,
+however, the lsof process doesn't surrender setgid permission, the
+modified personal path is read-only.
+
+If your dialect runs setuid-root or doesn't surrender its setgid
+permission, and you want to use the LSOFPERSDCPATH environment
+variable to address a collection of device cache files in a
+subdirectory, you will have to gather the collection in the
+subdirectory yourself with shell copy or move commands.
+
+====================================================================
+*								   *
+* The modified personal path option is enabled by default in the   *
+* lsof distribution with these definitions in the dialect's	   *
+* machine.h header file:					   *
+*								   *
+*	#define HASPERSDCPATH "LSOFPERSDCPATH"			   *
+* and								   *
+*	#define HASPERSDC "%h/%p.lsof_%L"			   *
+*								   *
+* The value of the definition is the name of the environment	   *
+* variable that contains the modified personal path name	   *
+* component that is inserted in the personal path when ``%p''      *
+* appears in HASPERSDC.  See the Default Personal Path section	   *
+* for a complete description of the ``%p'' conversion.		   *
+*								   *
+* To disable the modified personal path name component, disable	   *
+* the HASPERSDCPATH definition in the dialect's machine.h header   *
+* file -- e.g., change it to:					   *
+*								   *
+*	/* #define HASPERSDCPATH "LSOFPERSDCPATH" */		   *
+*								   *
+* or remove the definition altogether.  If you do this, don't	   *
+* forget to remove any ``%p'' conversion from HASPERSDC.	   *
+*								   *
+* The modified personal path option is disabled when HASDCACHE is  *
+* not defined.							   *
+*								   *
+* The modified personal path environment variable value is ignored *
+* when the lsof process is setuid-root or when the real UID of	   *
+* the lsof process is root (0).					   *
+*								   *
+* The modified personal path is read-only when the lsof process	   *
+* doesn't surrender its setgid permission.			   *
+*								   *
+====================================================================
+
+
+D. Displaying the Default Path
+==============================
+
+Whatever device cache file path formation options you decide to
+use, remember that the lsof help output, displayed in response to
+its ``-h'' or ``-?'' help options, will display the read-mode
+default (the highest numbered) path that lsof has been enabled to
+form from which it will read.
+
+Since some paths are read-only, the path displayed in help option
+output may not be the one to which lsof will write, should that
+become necessary.  To see the read-only and write device cache file
+paths, environment variable names, and the personal device cache
+file format specification (HASPERSDC), use the -D? option.
+
+
+Appendix A, Unix Dialects Without a Device Cache
+================================================
+
+Linux lsof implementations that obtain their information from files
+in the /proc file system do not have device cache support.  Generally
+lsof for Linux versions 2.1.72 and greater are /proc based.
+
+
+Appendix B, Lsof Dialects and Their Permissions
+===============================================
+
+These are the permissions recommended in the lsof distribution.
+
+
+Appendix B.1 Setuid-root Lsof Dialects 
+======================================
+
+These dialect versions of lsof need root permission.  For general
+use they may have to be installed setuid-root.
+
+    Apple Darwin 9 and Mac OS X 10.[567]
+    HP-UX 11.11 and 11.23
+    Linux (no device cache support needed)
+
+
+Appendix B.2 Setgid Lsof Dialects That Surrender Setgid Permission
+==================================================================
+
+Lsof versions for these dialects have WILLDROPGID defined in their
+machine.h header files.
+
+    AIX 5.[12] and 5.3-ML1
+    FreeBSD 4.x, 4.1x, 5.x and [6789].x for x86-based systems
+    FreeBSD 5.x, [6789].x fnd 10.xor Alpha, AMD64 and Sparc64-a
+	based systems
+    HP-UX 11.00
+    NetBSD 1.[456], 2.x and 3.x for Alpha, x86, and SPARC-based
+	systems
+    NEXTSTEP 3.[13]
+    OpenBSD 2.[89] and 3.[0-9] for x86-based systems
+    OPENSTEP 4.x
+    SCO OpenServer Release 5.0.4 for x86-based systems
+    SCO|Caldera UnixWare 7.1.4 for x86-based systems
+    Solaris 2.6, 8, 9 and 10
+    Tru64 UNIX 5.1
+
+
+Vic Abell <abe@purdue.edu>
+April 10, 2012
diff --git a/00DIALECTS b/00DIALECTS
new file mode 100644
index 0000000..16652de
--- /dev/null
+++ b/00DIALECTS
@@ -0,0 +1,5 @@
+	Apple Darwin 9 and Mac OS X 10.[567]
+	FreeBSD 4.9 and 6.4 for x86-based systems
+	FreeBSD 8.2, 9.0 and 10.0 for AMD64-based systems
+	Linux 2.1.72 and above for x86-based systems
+	Solaris 9, 10 and 11
diff --git a/00DIST b/00DIST
new file mode 100644
index 0000000..c1dcdbb
--- /dev/null
+++ b/00DIST
@@ -0,0 +1,4696 @@
+
+	    Notes for the distribution of lsof version 4
+
+********************************************************************
+| The latest release of lsof is always available via anonymous ftp |
+| from lsof.itap.purdue.edu.  Look in pub/tools/unix/lsof.         |
+********************************************************************
+
+		Contents
+
+	    Dialects Supported
+	    How Lsof Works
+	    Lsof Output
+	    Getting Started Quickly
+	    Limiting, Filtering, and Selecting Lsof Output
+	    Parsing Lsof Output with Another Program
+	    Repeat Mode
+	    Distribution Restrictions
+	    Cautions
+	    Distribution Contents
+	    Warranty
+	    Bug Reports
+	    The lsof-l Mailing List
+	    Version 3 Release Notes
+		3.0,  May 24, 1994
+		...
+		3.88, February 17, 1997
+	    What's New in Version 4
+	    Version 4 Release Notes
+		4.0, February 24, 1997
+		4.01, March 3, 1997
+		4.02, March 21, 1997
+		4.03, April 7, 1997
+		4.04, April 17, 1997
+		4.04 supplement, April 18, 1997
+		4.05, April 24, 1997
+		4.06, April 30, 1997
+		4.07, May 12, 1997
+		4.08, May 23, 1997
+		4.09, June 1, 1997
+		4.10, June 8, 1997
+		4.11, June 12, 1997
+		4.12, June 24, 1997
+		4.13, July 9, 1997
+		4.14, July 22, 1997
+		4.15, August 15, 1997
+		4.16, September 25, 1997
+		4.17, October 14, 1997
+		4.18, October 25, 1997
+		4.19, October 30, 1997
+		4.20, November 11, 1997
+		4.21, December 1, 1997
+		4.22, December 15, 1997
+		4.23, January 16, 1998
+		4.24, January 28, 1998
+		4.25, February 7, 1998
+		4.26, February 17, 1998
+		4.27, March 6, 1998
+		4.28, March 10, 1998
+		4.29, March 26, 1998
+		4.30, April 9, 1998
+		4.31, April 21, 1998
+		4.32, May 13, 1998
+		4.33, May 22, 1998
+		4.34, June 26, 1998
+		4.35, July 17, 1998
+		4.36, August 4, 1998
+		4.37, September 15, 1998
+		4.38, November 25, 1998
+		4.39, December 29, 1998
+		4.40, January 25, 1999
+		4.41, February 27, 1999
+		4.42, March 30, 1999
+		4.43, May 11, 1999
+		4.44, June 24, 1999
+		4.45, July 30, 1999
+		4.46, October 23, 1999
+		4.47, November 29, 1999
+		4.48, January 14, 2000
+		4.49, April 3, 2000
+		4.50, June 29, 2000
+		4.51, August 21, 2000
+		4.52, November 8, 2000
+		4.53, December 6, 2000
+		4.54, January 19, 2001
+		4.55, February 15, 2001
+		4.56, May 3, 2001
+		4.57, July 19, 2001
+		4.58, September 13, 2001
+		4.59, October 20, 2001
+		4.60, November 9, 2001
+		4.61, January 22, 2002
+		4.62, March 7, 2002
+		4.63, April 23, 2002
+		4.64, June 26, 2002
+		4.65, October 10, 2002
+		4.66, December 22, 2002
+		4.67, March 27, 2003
+		4.68, June 18, 2003
+		4.69, October 16, 2003
+		4.70, January 16, 2004
+		4.71, March 11, 2004
+		4.72, July 13, 2004
+		4.73, October 21, 2004
+		4.74, January 17, 2005
+		4.75, May 16, 2005
+		4.76, August 30, 2005
+		4.77, April 10, 2006
+		4.78, April 24, 2007
+		4.79, April 15, 2008
+		4.80, May 12, 2008
+		4.81, October 21, 2008
+		4.82, March 25, 2009
+		4.83, January 18, 2010
+		4.84, July 29, 2010
+		4.85, September 27, 2011
+		4.86, April 10, 2012
+		4.87, January 2, 2013
+
+
+Dialects Supported
+==================
+
+Lsof (for LiSt Open Files) lists files opened by processes on
+selected Unix systems.  Version 4 is a source reorganization of
+version 3, itself a major revision of version 2.  Version 4 has
+been tested on:
+
+	Apple Darwin 9 and Mac OS X 10.[567]
+	FreeBSD 4.9 and 6.4 for x86-based systems
+	FreeBSD 8.2, 9.0 and 10.0 for AMD64-based systems
+	Linux 2.1.72 and above for x86-based systems
+	Solaris 9, 10 and 11
+
+(The pub/tools/unix/lsof/contrib directory on lsof.itap.purdue.edu
+contains information on other ports.)
+
+If your favorite Unix dialect is not in the list, or if your version
+of it is more recent than the ones listed, please contact me at
+<abe@purdue.edu>.
+
+Version 3 of lsof was tested on:
+
+	AIX 3.2.5, 4.1[.[1234]], and 4.2
+	BSDI BSD/OS 2.0, 2.0.1, and 2.1 for x86-based systems
+	DC/OSx 1.1 for Pyramid systems
+	Digital UNIX (DEC OSF/1) 2.0, 3.0, 3.2, and 4.0
+	EP/IX 2.1.1 for the CDC 4680
+	FreeBSD 1.1.5.1, 2.0, 2.0.5, 2.1, 2.1.5 for x86-based
+		systems
+	HP-UX 8.x, 9.x, 10.01, 10.10, and 10.20
+	IRIX 5.2, 5.3, 6.0, 6.0.1, and 6.[124]
+	Linux through 2.0.27 for x86-based systems
+	NetBSD 1.0, 1.1, and 1.2 for x86 and SPARC-based
+		systems
+	NEXTSTEP 2.1 and 3.[0123]
+	OpenBSD 1.2 and 2.0 for x86-based systems
+	Reliant UNIX 5.43 for Pyramid systems
+	RISC/os 4.52 for MIPS R2000-based systems
+	SCO OpenServer Release 1.1, 3.0, and 5.0.x for x86-based 
+		systems
+	SCO UnixWare 2.1 and 2.1.1 for x86-based systems
+	Sequent PTX 2.1.[1569], 4.0.[23], 4.1.[024], 4.2[.1],
+		and 4.3
+	Solaris 2.[12345], 2.5.1, and 2.6-Beta
+	SunOS 4.1.x
+	Ultrix 4.2, 4.3, 4.4, and 4.5
+
+Version 3 and its predecessor, version 2, may be found at:
+
+	ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/OLD
+
+
+How Lsof Works
+==============
+
+Using available kernel data access methods -- getproc(), getuser(),
+kvm_*(), nlist(), pstat(), read(), readx(), /proc -- lsof reads
+process table entries, task table entries, user areas and file
+pointers to reach the underlying structures that describe files
+opened by processes.
+
+Lsof interprets most file node structures -- advfsnodes, autonodes,
+cnodes, cdrnodes, devnodes, fifonodes, gnodes, hsnodes, inodes,
+mfsnodes, pcnodes, procnodes, rnodes, snodes, specnodes, s5inodes,
+tmpnodes.  It understands NFS connections.  It recognizes FIFOs,
+multiplexed files, Unix and Internet sockets.  It knows about
+streams.  It understands /proc file systems for some dialects.  On
+many dialects it recognizes execution text and library references.
+It knows about AFS on some Unix dialects.
+
+
+Lsof Output
+===========
+
+The lsof output describes:
+
+    * the identification number of the process (PID) that has opened
+      the file;
+
+    * the process group identification number (PGID) of the process
+      (optional);
+
+    * the process identification number of the parent process (PPID)
+      (optional);
+
+    * the command the process is executing;
+
+    * the owner of the process;
+
+    * for all files in use by the process, including the executing
+      text file and the shared libraries it is using:
+
+      * the file descriptor number of the file, if applicable;
+
+      * the file's access mode;
+
+      * the file's lock status;
+
+      * the file's device numbers;
+
+      * the file's inode number;
+
+      * the file's size or offset;
+
+      * the name of the file system containing the file;
+
+      * any available components of the file's path name;
+
+      * the names of the file's stream components;
+
+      * the file's local and remote network addresses;
+
+      * the TLI network (typically UDP) state of the file;
+
+      * the TCP state, read queue length, and write queue length
+	of the file;
+
+      * the file's TCP window read and write lengths (Solaris
+	only);
+
+      * other file or dialect-specific values.
+
+
+Getting Started Quickly
+=======================
+
+If you want to get started using lsof quickly, or see some examples
+of how lsof can be used, consult the 00QUICKSTART file of the lsof
+distribution.
+
+The 00QUICKSTART file won't help you build or install lsof, but it
+will cut through the density of the lsof man page, giving you more
+readily an idea of what you can do with lsof.
+
+For information on building and installing lsof, consult the 00README
+file of the lsof distribution.
+
+
+Limiting, Filtering, and Selecting Lsof Output
+==============================================
+
+Lsof accepts options to limit, filter, and select its output.
+These are the possible criteria:
+
+    * Process ID (PID) number -- to list the open files for a given
+      process;
+
+    * Process Group ID (PGID) -- to list the open files for all
+      the processes of a given process group;
+
+    * User ID number or login name -- to list the open files for
+      all the processes of a given user;
+
+    * Internet address -- to list the open files using a given
+      Internet address (host name), protocol, or port (number or
+      name); or to list all open Internet files;
+
+    * command name;
+
+    * file descriptor name or number;
+
+    * list all open NFS files;
+
+    * list all open Unix domain socket files;
+
+    * list all uses of a specific file;
+
+    * list all open files on a file system.
+
+Selection options are normally ORed -- i.e., an open file meeting
+any of the criteria is listed.  The selection options may be ANDed
+so that an open file will be listed only if it meets all the
+criteria.
+
+In the absence of any selection criteria, lsof lists files open to
+all processes.
+
+
+Parsing Lsof Output with Another Program
+========================================
+
+The lsof -F option directs it to produce "field" output that can
+easily be parsed by another program.  The lsof distribution contains
+sample awk, perl 4, and perl 5 scripts in its scripts subdirectory
+that show how to post-process field output.
+
+
+Repeat Mode
+===========
+
+Lsof can be directed to produce output, delay for a specified time,
+then repeat the output, cycling until stopped by an interrupt or
+quit signal.  This mode is useful for monitoring the status of some
+file operation -- e.g., an ftp transfer or a tape backup operation.
+
+Repeat mode is more efficient when combined with lsof's selection
+options, since they limit lsof overhead.
+
+It's possible to use lsof's field output options to supply repeat
+mode output to another process for its manipulation.  The scripts
+subdirectory of the lsof distribution has sample Perl scripts
+showing how to consume lsof repeat mode output from a pipe.
+
+
+Distribution Restrictions
+=========================
+
+Lsof may be used and distributed freely, subject to these limitations:
+
+1. Neither the author nor Purdue University is responsible for
+   any consequences of the use of this software.
+
+2. The origin of this software must not be misrepresented, either
+   by explicit claim or by omission.  Credit to the author and
+   Purdue University must appear in documentation and sources.
+
+3. Altered versions must be plainly marked as such, and must not
+   be misrepresented as being the original software.
+
+4. This notice may not be removed from or altered in the lsof source
+   files.
+
+
+Cautions
+========
+
+Lsof is a tool that is closely tied to the Unix operating system
+version.  It uses header files that describe kernel structures and
+reads kernel structures that typically change from OS version to
+OS version.
+
+DON'T TRY TO USE AN LSOF BINARY, COMPILED FOR ONE UNIX OS VERSION,
+ON ANOTHER.
+
+On some Unix dialects, notably SunOS and Solaris, lsof versions
+may be even more restricted by architecture type.  An lsof binary,
+compiled for SunOS 4.1.3 on a sun4c machine, for example, won't
+work on a sun4m machine.
+
+AN LSOF BINARY, COMPILED FOR ONE SOLARIS 1.X ARCHITECTURE, ISN'T
+GUARANTEED TO WORK ON A DIFFERENT SOLARIS 1.X ARCHITECTURE.
+
+
+Distribution Contents
+=====================
+
+The lsof distribution is checked for completeness when it is
+constructed and by the Inventory script when you run the Configure
+script.  (See The Inventory Script section of the 00README file of
+this distribution.)
+
+Lsof is organized in these parts:
+
+    *  The main lsof directory, containing common sources,
+       configuration and setup scripts and three subdirectories:
+       dialects/, lib/, and scripts/.
+
+       Lsof is compiled in the main lsof directory after configuration.
+       The selected dialect sources are copied or linked from the
+       specified subdirectory.  (Symbolic linking is the standard
+       method.)
+
+       Common lsof definitions may be found in lsof.h; common
+       function prototypes, proto.h; and common storage, store.c.
+
+    *  The dialects/ subdirectory contains subdirectories with
+       sources specific to UNIX dialect implementations -- e.g.,
+       the dialects/sun/ subdirectory contains sources for the
+       SunOS (Solaris 1.x) and Solaris (2.x) implementations of
+       lsof.  The dialects subdirectories also contain Makefiles
+       and scripts for assisting dialect source configuration.
+
+       Dialect configuration definitions may be found in dlsof.h;
+       other dialect definitions, dlsof.h; dialect prototypes,
+       dproto.h; and dialect storage, dstore.c.
+
+    *  The lib/ subdirectory contains sources for common lsof
+       functions.  Not all dialects use the functions -- some have
+       their own versions of them.  The lib/ functions are enabled
+       and customized with #define's in the dialect machine.h header
+       files.
+
+    *  The scripts/ subdirectory contains sample scripts for
+       processing lsof field (-F) output.  The scripts are written
+       in AWK, Perl 4, and Perl 5.
+
+The 00PORTING file of the lsof distribution has more information
+on lsof components, configuration, and construction.
+
+
+Warranty
+========
+
+Lsof is provided as-is without any warranty of any kind, either
+expressed or implied, including, but not limited to, the implied
+warranties of merchantability and fitness for a particular purpose.
+The entire risk as to the quality and performance of lsof is with
+you.  Should lsof prove defective, you assume the cost of all
+necessary servicing, repair, or correction.
+
+
+Bug Reports
+===========
+
+Now that the obligatory disclaimer is out of the way, let me hasten
+to add that I accept lsof bug reports and try hard to respond to
+them.  I will also consider and discuss requests for new features,
+ports to new dialects, or ports to new OS versions.
+
+PLEASE DON'T SEND A BUG REPORT ABOUT LSOF TO THE UNIX DIALECT
+VENDOR.
+
+At worst such a bug report will confuse the vendor; at best, the
+vendor will forward the bug report to me.
+
+Please send all bug reports, requests, etc. to me via email at
+<abe@purdue.edu>.
+
+
+The lsof-l Mailing List
+=======================
+
+Information about lsof, including notices about the availability
+of new revisions, may be found in mailings of the lsof-l listserv.
+For more information about it, including instructions on how to
+subscribe, read the 00LSOF-L file of the lsof distribution.
+
+
+Version 3 Release Notes
+=======================
+
+See 00DIST in the last lsof 3 revision 3.88, for its complete
+set of release notes.  Lsof revision 3.88 may be found at:
+
+	ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/OLD
+
+3.0		May 24, 1994
+		This is the first official release of lsof 3.
+
+...
+
+3.88		February 17, 1997
+
+		+======================================+
+		| This is the last version 3 revision. |
+		+======================================+
+
+		Added documentation files -- 00.README.FIRST[_<version>]
+		and 00RELEASE.SUMMARY_<version> -- to the distribution.
+
+
+What's new in Version 4
+=======================
+
+The main goal of version 4 was to eliminate the confusing common/
+fragment source file technique.  Changing the version number also
+provided an opportunity to restart the numbering, which at 3.88
+had risen to a large value.
+
+The sources that appeared in the dialects/common subdirectory of
+version 3 in fragment files have been incorporated into the version
+4 liblsof.a library as *.c files.  This results in significant
+changes to many source files, scripts, and Makefiles of all dialect
+versions.  It allows elimination of some source files -- ddev.c,
+dfile.c, dmnt.c -- for dialects now obtaining functions from
+liblsof.a that formerly came from making dialect source files by
+combining fragment files.
+
+The version 4 liblsof.a sources are stored in the lib/ subdirectory
+of the main lsof directory.  The liblsof.a functions are activated
+and conditioned in their source files by values #define'd in the
+dialect dlsof.h and machine.h header files.
+
+Dialects that provide a private version of a library function refrain
+from #define'ing the symbol that would activate the library function
+code.
+
+
+Version 4 Release Notes
+=======================
+
+4.0		February 24, 1997
+
+		+====================================+
+		| This is the first lsof 4 revision. |
+		+====================================+
+
+		Reorganized sources: eliminated code fragment files
+		and created a library in their place.  Modified or
+		deleted many dialect source and header files.
+		Changed documentation accordingly.
+
+		Added a warning to sgi/Makefile and 00FAQ that advises
+		against using the IRIX C compiler -n32 option when
+		compiling lsof.  Thanks go to Peter Ilieve
+		<peter@memex.co.uk> for bringing this to my attention.
+
+		Dropped IRIX 5.2 in mid-stream, because my 5.2 test
+		system was upgraded to 5.3.
+
+4.01		March 3, 1997
+		Added TFS support for Pyramid dialects.
+
+		Added test to Configure and to the IRIX dnode.c
+		for the different cnode struct that appears in
+		<cachefs/cachefs_fs.h> on the 6.2 IMPACT distribution.
+		Heddy Boubaker <boubaker@amfou.cenatls.cena.dgac.fr>
+		alerted me to the cnode change and helped test this
+		lsof adjustment.
+
+		Shut down the lsof child process before doing a -r
+		sleep().  A comment from Dan Mercer <dam@mmm.com>
+		prompted this.
+
+4.02		March 21, 1997
+
+		Based on a report from Pasi Kaara <Pasi.Kaara@atk.tpo.fi>,
+		disabled HP-UX CCIT support in lsof for HP-UX
+		versions 10 and above.  Pasi's report also led to
+		changes in the HP-UX machine.h to support use of
+		gcc to compile lsof for HP-UX 10.20 and warnings
+		against using `cc -Aa` or `gcc -ansi` to compile
+		lsof under HP-UX 10.x.
+
+		With help from Richard Allen <ra@hp.is> taught
+		HP-UX 10.x lsof to name file systems better by
+		using the virtual file system device number.  Elias
+		Halldor Agustsson <elias@rhi.hi.is> provided a test
+		system.
+
+		Changed NEXTSTEP and UNIXWARE Makefiles to use
+		safer quoting when generating version.h.  The change
+		was suggested by Bob Farmer <ucs_brf@unx1.shsu.edu>.
+
+		Added SHELL=/bin/sh string to all Makefiles.
+
+		Added support for Linux 2.1.28 on a test system,
+		kindly provided by Jonathan Sergent <sergent@purdue.edu>.
+		Configure tests the Linux 2.1.x's C library lseek()
+		function for proper handling of kernel offsets.
+		If lseek() appears suspect, Configure activates
+		the use of a private lseek() function.  Changed
+		the private nlist() function to nlist_private()
+		and taught it to use the query_module() syscall in
+		place of the deprecated get_kernel_syms() one.
+		Added rudimentary AX.25 support for Pierfrancesco
+		Caci <ik5pvx@infogroup.it> who helped test it.
+		Updated the old get_kernel_syms() code to recognize
+		and skip module name entries.
+
+		Prompted by Marty Leisner <leisner@sdsp.mc.xerox.com>,
+		eased the requirement that service name lookup for
+		the -i option be accompanied by a protocol name.  The
+		name is not needed if both TCP and UDP names yield the
+		same port number.
+
+		Added xusers.awk script from Dan Mercer <damercer@mmm.com>
+		to the distribution scripts/ subdirectory.
+
+		Changed Configure script to use LSOF_VERS for all
+		UNIX dialect version numbers and to pass LSOF_VERS
+		to the dialect Mksrc functions.  Also added the
+		ability for a dialect stanza to declare a different
+		dialect Makefile source.  Modified dialect Mksrc
+		files -- e.g., linux and sun -- accordingly.
+
+		Added support for BSD/OS 3.0 with help from Jim
+		Reid <jim@mpn.cp.philips.com>.  Terry Kennedy
+		<TERRY@spcvxa.spc.edu> kindly provided a test
+		system.  During the port corrected a bug that
+		prevented proper handling of revoked files.
+
+4.03		April 7, 1997
+		At the suggestion of Dan Mercer <damercer@mmm.com>,
+		made HP-UX building of lsof aware of differences
+		between the HP-UX bundled and unbundled C compilers.
+
+		Added the ability for the lsof builder to define the
+		default warning message issuance state.  By default the
+		issuance of warning messages is disabled; defining
+		WARNINGSTATE in machine.h disables it.  The Customize
+		script was updated to handle WARNINGSTATE.  Dan Mercer
+		suggested this.
+
+		Eliminated compiler complaint about improperly cast
+		get_Nl_value() argument in ncache_load() in lib/rnch.c.
+
+		Corrected zeromem() argument error in SCO dproc.c.
+		Sped up parent directory cache lookup slightly.
+
+		Updated for PTX 4.4, including additional VxFS (EFS)
+		file system support.
+
+4.04		April 17, 1997
+		At the suggestion of Bela Lubkin <belal@sco.COM>
+		changed device cache handling to be more tolerant
+		of a device cache file whose [cm]times are older
+		than the ones on /dev or /devices.  The change
+		required adding information to Solaris device cache
+		file clone lines, so the first time lsof 4.04 is
+		run under Solaris it will complain about a bad
+		cached clone device in a previous device cache
+		file, then regenerate it.
+
+		Added boot file path detection for SCO OSR 5 and
+		above, based on information supplied by Bela.
+
+		Fixed two bugs in DEC OSF/1 lsof -- an error in
+		reporting locks and a missing continue statement
+		in readdev() after a failure to open a directory.
+		Jan Ole Suhr <josuhr@informatik.tu-clausthal.de>
+		reported the second bug and supplied a fix.
+
+		Fixed XFS problems with IRIX 6.2 by abandoning the
+		idea that SGI will distribute XFS header files and
+		defining an lsof-private xfs_inode structure.  John
+		Paul Morrison <John.Paul.Morrison@MultiActive.com>
+		helped develop and test the 5.3 definition.  John
+		R. Vanderpool <fish@daacdev1.gsfc.nasa.gov> helped
+		develop and test the 6.2 definition.
+
+		Remove obsolete comments about common/*.frag files.
+
+		Updated Linux lsof for Linux version 2.1.35.
+
+4.04		April 18, 1997
+Supplement	Regenerated the 4.04 distribution to correct a non-
+		device-cache #define misplacement in the Solaris and
+		SunOS dlsof.h.  Alexandre Oliva <oliva@dcc.unicamp.br>
+		reported the problem.
+
+4.05		April 24, 1997
+		Corrected an error in 00DCACHE.
+
+		Made sure SCO /etc/ps/booted.systems is closed.
+
+		Based on an observation by Bela Lubkin <belal@sco.COM>
+		that the lsof child had needless file descriptors
+		open, closed all but the open pipes between the
+		lsof parent and child.
+
+		Decommissioned CDC EP/IX support; I no longer have a
+		test system.
+
+		Based on a suggestion from Patrick Connor
+		<connor@phreak.csd.sgi.com>, added -xansi to CFLAGS
+		for IRIX 5.3 and 6.[234].
+
+		Also at Patrick's suggestion changed Configure to
+		propagate exact SunOS 4.1.x version to the main
+		and library Makefiles.  This allowed the sunos413
+		and sunos413cc Configure abbreviations to be
+		shortened to sunos and sunoscc.
+
+		Updated obsolete argument uses (-H changed to -n)
+		in count_pf.perl* and watch_a_file.perl scripts.
+
+		Adjusted Solaris 2.6 lsof for Beta_Update with tips
+		from Casper Dik <casper@holland.Sun.COM>.
+
+		Fixed a Solaris 2.4 TCP address reporting bug.
+
+4.06		April 30, 1997
+		Added a step to the Makefile clean rules that does
+		a make clean in the lib subdirectory; suggested by
+		Casper Dik <casper@holland.Sun.COM>.  (Configure's
+		-clean argument already did this.)
+
+		Fixed an incorrect awk argument in the sunos*)
+		Configure stanza, reported by Alexandre Oliva
+		<oliva@dcc.unicamp.br>.
+
+		Added CD9660 (aka ISO) file system support to
+		FreeBSD, NetBSD, and OpenBSD with mods and help
+		from Kenneth Stailey <kstailey@disclosure.com>.
+		(BSDI already had CD9660 support.)  While at it,
+		added file descriptor system support to BSDI and
+		FreeBSD.
+
+		Added /kern file system support to OpenBSD.  The
+		support wasn't extended to BSDI, FreeBSD, or NetBSD,
+		because it requires Kenneth Stailey's changes to
+		/sys/miscfs/kernfs/kernfs.h.
+
+		Updated IRIX 6.3 support after getting access to
+		a test system, provided by John Paul Morrison
+		<John.Paul.Morrison@MultiActive.com>.  Improved
+		the handling of IRIX 5.1 and greater FIFOs.
+
+4.07		May 12, 1997
+		Based on AIX problem reports from David Capshaw
+		<David.Capshaw@SEMATECH.Org>, changed the aix*
+		Configure script stanza to avoid -bnolibpath for
+		gcc (which the GNU loader doesn't grok) and AIX
+		below 4.1.4 (where -bnolibpath hasn't been tested
+		or is known to be unimplemented), and to refuse to
+		use gcc for compiling lsof in AIX versions below
+		4.1 (because of possible structure alignment
+		problems).  Updated 00FAQ appropriately.
+
+		Added OpenBSD support for EXT2FS.  This support
+		has yet to be tested.
+		
+		Tested lsof under OpenBSD 2.1.
+
+		Activated /kern file system support for NetBSD when
+		Configure senses that /sys/miscfs/kernfs/kernfs.h
+		defines the kern_target structure.  This support
+		has not been tested under NetBSD, although it has
+		been tested under OpenBSD.
+
+		Made some simple changes to the BSDI machine.h,
+		suggested by Jeffrey C. Honig <jch@bsdi.com>.
+
+		Improved handling of alternate dialect Configure
+		abbreviations -- aix and aixgcc, hpux and hpuxgcc,
+		solaris and solariscc, and sunos and sunoscc.
+
+4.08		May 23, 1997
+		Cleaned up dialect Makefile's, staring with a suggestion
+		from Christopher Schanzle <chris@cam.nist.gov>.
+
+		Improved Configure's -clean processing.
+
+		Corrected bugs in Solaris lock reporting.
+
+		Changed NetBSD Configure stanza to put -I/usr/include
+		before -I/sys.
+
+4.09		June 1, 1997
+		Adjusted for latest FreeBSD 3.0 release.  This
+		required adding a new kernel name cache module for
+		reading BSD-form hashed kernel name cache entries,
+		rnmh.c, to the lsof library, and adding a #define
+		to each machine.h to select it.
+
+		Activated rnmh.c for BSDI 2.1, BSDI 3.0, NetBSD
+		1.2, and OpenBSD 2.1.
+
+4.10		June 8, 1997
+		Adjusted for Linux 2.1.x (x > 35) kernels with
+		hashed task structure pointers.  Marty Leisner
+		<leisner@sdsp.mc.xerox.com> and Jonathan Sergent
+		<sergent@io.com> tested the adjustment.
+
+		Replaced readdev() stat() calls with lstat() to
+		reduce device table and cache entries with the same
+		device number and inode values.  Added code to
+		remove all remaining duplicates.  This fixes a
+		Linux problem reported by Jonathan Sergent and
+		makes device node name output predictable.
+
+		Corrected a bug in UnixWare stream file handling
+		that prevented searching for the stream file by
+		its associated character device name.
+
+		Added Pyramid code to determine Reliant UNIX clone
+		major device number differently from that of DC/OSx.
+
+4.11		June 12, 1997
+		Changed Configure to sense that the PTX inp_[fl]addr
+		members of the inpcb structure of <netinet/in_pcb.h>
+		have a struct type and set HASINADDRSTR for use in
+		PTX dnode.c and dsock.c tests.
+
+		Changed PTX version 4.1.4 tests to use 4.1.3 instead.
+		Carson Wilson <carson@mcs.com> reported the need
+		to do this and tested the change.
+
+		Fixed a block device table indexing bug in lib/rdev.c,
+		reported by Carson Wilson.  The same bug was squashed
+		in pyramid/ddev.c.
+
+		Added code to the Pyramid Reliant UNIX kread()
+		function to compensate for an address boundary
+		error in the kernel's /dev/kmem driver.
+
+		Verified that lsof compiles and works under AIX
+		4.2.1.  Added an AIX test for the presence of NFS
+		header files, defined HAS_NFS and adjusted AIX
+		dialect sources accordingly.
+
+		Based on a suggestion from Gaylord Holder
+		<holder@phy.ucsf.EDU>, added DEC OSF/1 code to
+		auto-detect the booted file, whence kernel symbol
+		addresses are obtained.
+
+4.12		June 24, 1997
+		Corrected a device number sign extension problem
+		in the reading and writing of device cache file.
+		The problem was reported by Bela Lubkin <belal@sco.com>
+		and he suggested a fix.
+
+		Fixed an SCO stream device lookup problem.  The
+		report and solution came from Bela Lubkin
+
+		Enhanced the Configure script to enable cross-
+		configuration of lsof, based on suggestions from
+		Marty Leisner <leisner@sdsp.mc.xerox.com>.  A new
+		documentation file, 00XCONFIG, describes the process.
+
+		Made Pyramid OBJFS support conditional on the
+		presence of supporting header files.  Corrected
+		the Pyramid MkKernOpts script so it generates the
+		necessary -D's for the Nile/Jolt architecture.
+		Richard Coley <rcoley@pyra.co.uk> helped.
+
+		Added another IRIX xfs_inode variant for 6.2, 32
+		bits, no XFS rollup patch.
+
+		Tested under UnixWare 2.1.2.
+
+4.13		July 9, 1997
+		Taught Pyramid lsof to grok ttyfs vnodes with help
+		from Richard Coley <rcoley@pyra.co.uk>.  Fixed some
+		minor bugs in Pyramid FIFO reporting.  Eliminated
+		use of the Pyramid UCB compatibility library at
+		Richard's suggestion.
+
+		Eliminated reporting of "strange" inode numbers
+		for SCO OSR 3.2v5.0.x HPPS files with help from
+		Bela Lubkin <belal@sco.com>
+
+		Modified port to service name lookup to use a small
+		number of getservbyport() calls before reading the
+		entire map with getservent().  Changed port reporting
+		to represent a zero as `*' to be consistent with
+		other prt number reporting tools like netstat.
+		Casper Dik <casper@holland.Sun.COM> suggested these
+		changes -- the getserv*() one to improve performance
+		for large NIS service name maps.
+
+		Changed all readdev() functions to make the absence
+		of block devices a warning instead of a fatal error
+		after Brian Redman <ber@ms.com> reported his IRIX
+		6.4 system had no block devices.  (It really did
+		have block devices, but readdev()'s lstat() use
+		caused it to miss them in a directory symbolically
+		linked from /dev/dsk->/hw/disk.)  Fixed Brian's
+		real problem by changing the IRIX readdev() to use
+		stat() on /dev nodes if a Configure test shows /hw
+		is readable.  Extended the potential to do the same
+		to all readdev() functions.
+
+		For consistency and convenience changed some
+		Configure abbreviations and dialect subdirectory
+		names:  "decosf" abbreviation and "osf" dialect
+		subdirectory name to "du"; "netbsd" dialect
+		subdirectory name to "n+obsd"; "next3" abbreviation
+		and "next" dialect subdirectory name to "ns"; "sco"
+		abbreviation and dialect subdirectory name to "osr";
+		"sgi" dialect subdirectory name to "irix"; and
+		"unixware" abbreviation and dialect subdirectory
+		name to "uw".
+
+		Added #if/#endif clauses to the AIX rmdupdev()
+		function to avoid clone processing for AIX versions
+		less than 4.1.4.  The problem was reported by Toralf
+		Foerster <toralf.foerster@io-warnemuende.de>, who
+		supplied corrective code.
+
+		Added support for new style NetBSD inode with i_ffs
+		and i_e2fs union members.
+
+		Improved Configure and 00FAQ information on Digital
+		UNIX configuration subdirectory with suggestions
+		from Brad Krebs <brad@EECS.Berkeley.EDU>.
+
+4.14		July 22, 1997
+		Reorganized the Solaris handling of the inode
+		structure header file, ufs_inode.h, to eliminate
+		VxFS structure definition conflicts for Solaris
+		2.4, based on information from Greg Earle
+		<earle@netbsd4me.jpl.nasa.gov>.
+
+		Cleaned up some typos and confusion in Configure's
+		help output, based on comments from Bela Lubkin
+		<belal@sco.com>
+
+		Added a 00DIALECTS file, containing UNIX dialect
+		version numbers, that can be used by Configure and
+		the man page.
+
+4.15		August 15, 1997
+		Aligned `Configure -help` output better.  Removed
+		Configure's 2.6 Beta test adjustments.
+
+		Added improved Solaris VxFS configuration and
+		handling, based on information from Greg Earle
+		<earle@netbsd4me.jpl.nasa.gov>.
+
+		Added socket state -- TCO or TPI -- for socket
+		files at the suggestion of Ian Fitchet
+		<I.D.Fitchet@ftel.co.uk>.
+
+4.16		September 25, 1997
+		Added reporting of TCP/TPI queue lengths and window
+		sizes ala netstat to NAME column.  Added -T option
+		to select or de-select TCP/TPI info reporting.
+		(Window sizes are only reported for Solaris.)
+		Fixed anomalies along the way in SIZE/OFF processing
+		for some dialects.
+
+		Fixed service name argument processor to allow
+		minus signs as part of the name.  Consequently this
+		disallows names with embedded minus signs from
+		being specified as the start of a range.
+
+		Added 00FAQ entries explaining why lsof won't find
+		a file being edited with vi, why window sizes aren't
+		reported for all dialects, and what the "no more
+		information" message means.
+
+		Forced Pyramid CC to be /usr/ccs/bin/cc to avoid
+		accidental use of the BSD variant in /usr/ucb/cc.
+
+		Added support for Linux glibc2, including a Configure
+		test; cross-Configure support (00XCONFIG); and much
+		unfortunate and risky sleight-of-hand in lsof Linux
+		dialect header and source files, forced upon lsof
+		by incompatibilities between Linux kernel and glibc2
+		header files.
+
+		Included in scripts/identd.perl5 a Perl 5 implementation
+		of an identd server, using lsof, provided by Kapil
+		Chowksey <kchowksey@hss.hns.com>.
+
+		Updated IRIX 6.4 xfs_inode guess.
+
+4.17		October 14, 1997
+		Added -V option for verbose search result reporting.
+		Verbose reports are prepared for failure to locate
+		file names, command names, Internet addresses or
+		files, login names, NFS files, PIDs, PGIDs, and UIDs.
+
+		Augmented Linux NFS file test to cope with kernels
+		whose NFS code is in a loadable module.  Need for
+		the test was pointed out by Jonathan Sergent
+		<sergent@csociety.ecn.purdue.edu>.  The change
+		required that Linux have private dmnt.c source,
+
+		Completed a Linux 2.1.57 port on a system provided
+		by Jonathan Sergent.
+
+4.18		October 25, 1997
+		Eliminated memory leaks in alloc_lfile(), lkup_port(),
+		and NEXTSTEP's process_text() function.
+
+		Added recognition of OpenBSD 2.2 in Configure,
+		supplied by Kenneth Stailey <kstailey@disclosure.com>.
+
+		Consolidated print_file() functions to use the one
+		in lib/prtf.c.  Made it configurable and changed
+		it to size print columns dynamically.
+
+		!!! WARNING !!!
+
+		WITH DYNAMICALLY SIZED PRINT COLUMNS LSOF 4.18
+		PRODUCES OUTPUT SIGNIFICANTLY DIFFERENT FROM THAT
+		OF PREVIOUS REVISIONS.  LINES ARE GENERALLY SHORTER
+		AND THERE IS GENERALLY LESS BLANK SPACE BETWEEN
+		COLUMNS AND THE ITEMS IN THEM.  THERE ARE NO LONGER
+		ANY SPACES BETWEEN DEVICE NUMBER ELEMENTS, ONLY
+		COMMAS.
+
+		!!! WARNING !!!
+
+		Added special types and print specification modifiers
+		for file size and offset to handle UNIX dialects
+		with 64 bit sizes and offsets.  Paul Eggert
+		<eggert@twinsun.com> reported the need for this
+		addition.
+
+		With Paul Eggert's help picked lint from the lsof
+		library, the main level lsof sources, and the Sun
+		dialect sources.
+
+		Added documentation, including the file 00LSOF-L,
+		about the lsof-l LISTSERV.
+
+		Added support for Reliant UNIX on the RM600.  Bob
+		Passarella <rmpassar@pyramid.com> supplied the
+		changes.  Kevin Smith <kevin@pyramid.com> helped
+		arrange test systems.  While incorporating Bob's
+		changes, modified lib/rnch.c to handle kernel ncache
+		structs whose name is accessed via a char *, rather
+		than in a char array.
+
+		Changed #include order of <sys/socketvar.h> for
+		Solaris 2.x.  W. Richard Stevens <rstevens@kohala.com>
+		pointed out the need to do this.
+
+4.19		October 30, 1997
+		Changed Pyramid Reliant RM600 proc scan to skip
+		SSYS (p_flag) processes, since they don't seem to
+		have a readable u_cdir vnode.
+
+		Enabled Pyramid Reliant UNIX kread() work-around
+		for DC/OSx, too, since its read(/dev/kmem) kernel
+		driver seems to share the page boundary bug this
+		work-around circumvents.
+
+		Changed SzOffFtm_d and SzOffFtm_dv (new formats at
+		4.18 to print size and offset) from signed to
+		unsigned.  Setting them signed at 4.18 was an
+		oversight.
+
+		Plugged a memory leak that caused the loss of 130
+		bytes per repeat-mode pass.  Fixed it with a simple
+		work-around in main().  Lionel Cons <Lionel.Cons@cern.ch>
+		reported the leak.
+
+4.20		November 11, 1997
+		Tested under BSDI 3.1.
+
+		Added support for Reliant UNIX Mesh IPC files with
+		help from Billy Ho <bho@pyramid.com>.
+
+		Added support to Digital UNIX lsof that uses the
+		libmsfs tag_to_path() function (when it exists) to
+		look up AdvFS path names.  The idea and sample code
+		came from Dean Brock <brock@cs.unca.edu>.  Converted
+		Dean's code into more general purpose support for
+		private name cache lookups via the HASPRIVNMCACHE
+		#define in the dialect machine.h file and code
+		conditional on it in the printname() function.
+
+		Taught Digital UNIX lsof to recognize NFS3 file
+		systems.  Corrected Digital UNIX lsof DEVICE column
+		alignment.
+
+4.21		December 1, 1997
+		Squashed bug, introduced at revision 4.18, that
+		resulted in double reporting of each selected PID
+		when terse mode (-t) was specified.
+
+		Corrected minor bug, also introduced at 4.18, that
+		might cause an extra print_proc() pass when one
+		PID has been specified.
+
+		Added -R to lsof options in scripts/idrlogin.perl*.
+		The option should have been there -- it was supposed
+		to be mandatory for PGID reporting -- but a bug,
+		corrected in revision 4.18, previously made -R
+		unnecessary.
+
+		Enabled configuring for BSDI BSD/OS 4.0 per a
+		suggestion from Jeff Honig <jch@bsdi.com>.
+
+		Enabled replacement of scoff_t with off64_t (scoff_t
+		is used to type r_size and r_localsize in the rnode
+		struct) for IRIX 5.3 systems that have the NFS
+		kernel rollup patch (1477).  This compensates for
+		SGI's failure to distribute an updated <sys/fs/rnode.h>
+		with their patch.
+
+		Validated under Linux 2.0.3[12], Linux 2.1.64, and
+		NetBSD 1.3.
+
+		Added FreeBSD root directory reporting, courtesy
+		of Dan Nelson <dnelson@emsphone.com>.
+
+4.22		December 15, 1997
+		Made adjustments for Linux 2.1.7[02].
+
+		Improved NAME information for Linux UNIX domain
+		sockets.
+
+		Added option +|-M to control the reporting of
+		portmapper registration information in square
+		brackets after the TCP or UDP port or service name.
+		Kenneth Stailey <kstailey@disclosure.com> suggested
+		the feature and provided sample code from OpenBSD.
+		Reporting is disabled by default in the distribution
+		and may be enabled with +M; if lsof is compiled
+		with HASPMAPENABLED (e.g., from machine.h), reporting
+		will be enabled by default and can be disabled with
+		-M.
+
+		Changed the -w option to +|-w to match the syntax
+		of the +|-M option and to eliminate any options
+		that flip meaning when a symbol is defined at
+		compile time.  For both +|-M and +|-w, specifying
+		`-' when the default state is disabled or specifying
+		`+' when the default state is enabled causes no
+		problems.
+
+	!!!WARNING  The -w option has changed in lsof 4.22.  WARNING!!!
+
+		Made the +|- prefix legal for most options, but
+		didn't document it in the man page or help panel.
+		Most options that disable something -- e.g., -b,
+		-C, -n, -P -- now disable when the prefix is `-'
+		and enable when it is `+'.  Since the states these
+		options disable are enabled by default, I chose to
+		avoid documentation complexity and confusion by
+		not mentioning that they can be used with the `+'
+		prefix.
+
+		Condensed the help panel.
+
+		Made sure Digital UNIX Configure stanza puts normal
+		include path (e.g., /usr/include) before system
+		include paths.
+
+		Added IPX socket information reporting to Linux
+		with help from Jonathan Sergent <sergent@purdue.edu>.
+
+4.23		January 16, 1998
+		Fixed conflict arising from the quondam replacement
+		of the Sun Solaris <netdb.h> with a BIND/BSD version.
+
+		With help from Jonathan Sergent <sergent@purdue.edu>
+		developed a /proc file system based Linux lsof.
+		It needs some Linux 2.1.x release to work -- I'm
+		not sure which, but I tested under 2.1.72, 2.1.76,
+		and 2.1.79.  The Configure script selects special
+		sources for this lsof, so the full lsof distribution
+		now contains both /dev/kmem and /proc based sources
+		for Linux lsof.  An optional kernel mod, written
+		by Jonathan, enhances the /proc-based lsof ability
+		to recognize IPX socket files.  Reorganized and
+		augmented the Linux sections in 00FAQ to explain
+		the two types of Linux lsof.
+
+		Defined DOSTAT_FUNCTION for dostat() in misc.c to
+		select the function, stat() or lstat(), it will use.
+		DOSTAT_FUNCTION is normally undefined, defaults to
+		lstat(), and is only defined for the /proc-based
+		Linux lsof in its dlsof.h.
+
+		Made conditional on the presence of IRIX 6.4 XFS
+		rollup patch #6 an XFS node change introduced in
+		revision 4.16.   Identified the patch with help
+		from John R. Vanderpool <fish@daacdev1.gsfc.nasa.gov>.
+
+		Added NFS node compensation for NetBSD 1.3.  The
+		code and suggestion for it was supplied by Jean-Luc
+		Richier <richier@imag.fr>.
+
+		Added diagnostic messages to the /dev/kmem-based
+		Linux Mksrc script to report errors during the
+		construction of the kernel name cache header file,
+		kncache.h.  Added 00FAQ information on kncache.h.
+
+		Added a new Linux test host, running 2.0.33 and
+		GlibC, provided by Steve Logue <stevel@mail.cdsnet.net>.
+
+		Ported to PTX 4.1.3 and 4.4.2.  Adjusted lib/rnch.c
+		for 4.4.2 to allow customization f additional ncache
+		struct element names.
+
+4.24		January 28, 1998
+		Changed /proc-based Linux lsof offset test to use "/"
+		instead of "/etc/passwd".
+
+		To assist Jim Mintha <jim@geog.ubc.ca> with the
+		packaging of lsof for Debian Linux, added a
+		DEBIAN_LINUX_LSOF #define to trigger the activation
+		of special system map file location code in the
+		/dev/kmem-based dproc.c.
+
+		Applied modification to dialects/bsdi/dlsof.h from
+		Ingimar Robertson <iar@skyrr.is>, enabling lsof to
+		compile for BSDI BSD/OS 2.0.
+
+		Corrected a documentation error in 00DCACHE, pointed
+		out by Thomas Anders <anders@hmi.de>.  The error was
+		created when the -V option was added at lsof 4.17.
+
+		Made IRIX 5.3 through 6.3 lsof aware of IRIX SCSI
+		tape devices (e.g., /dev/tape).  Dave Olson of SGI
+		and Randolph J. Herber of FNAL provided valuable
+		advice, and Igor Schein <ischein@air-boston.com>
+		helped test.
+
+		Added a machine.h symbol (NEVER_HASDCACHE) that
+		prevents Customize from offering to change HASDCACHE.
+		The symbol may appear anywhere in machine.h --
+		e.g., in a comment.  Included the symbol in a
+		comment of the HASDCACHE section of the /proc-based
+		Linux lsof machine.h, and accompanied it with
+		warnings against #define'ing HASDCACHE.  Did the
+		same thing for WARNDEVACCESS (NEVER_WARNDEVACCESS
+		is the suppressant.)
+
+4.25		February 7, 1998
+		Corrected an IRIX mis-cast of file offset (position).
+		Igor Schein <ischein@air-boston.com> reported the
+		problem.  This was offered as a patch to 4.24.
+		Picked some lint Igor pointed out.
+
+		At Igor's suggestion added an optional decimal
+		digit size argument to the -o option.  This argument
+		specifies how many file offset decimal digits can
+		follow "0t" before lsof switches to a "0x..." form.
+		The argument size specification doesn't count the
+		two characters of the "0t".  A size of 0 means
+		unlimited.  The default is OFFDECDIG (8), preserving
+		compatibility with existing lsof output; it can be
+		changed by the lsof builder.  When size is specified
+		with -o it does not force offset display; -o without
+		a size still must be used to do that.
+
+		Added an IRIX 6.2, 32 bit system, XFS node patch,
+		courtesy of Ulrich Bernhard <rzubu@rzu.unizh.ch>.
+
+		For my own convenience enabled Configure to use
+		/usr/local/bin/gcc for NEXTSTEP.  This allows
+		circumvention of a gcc 2.8.0 ranlib problem on
+		my test 3.1 `040 cube.
+
+		Added flags recommended by the RISC/os and Ultrix
+		compilers for the updated (and longer) main.c.
+
+		Updated FreeBSD cd9660_node.h Configure test.
+
+4.26		February 17, 1998
+		Added shared process group processing for IRIX 5.3,
+		and IRIX 6.1 and above, based on investigation of
+		a bug report from Igor Schein <ischein@air-boston.com>.
+		Igor helped test this addition.
+
+		Improved handling of file system name arguments.
+		It's now done in a manner similar to fuser.  The
+		-f argument forces path names to be considered as
+		simple files, rather than as file system names.
+		The +f flag forces them to be considered as file
+		system names.  Normally path arguments are considered
+		file system names when they match a mounted-on
+		directory in the system's mount table, or when they
+		match a mounted file system's block device.  Igor
+		Schein helped test this change.
+
+		Igor also suggests that the proper compilation of
+		the IRIX 6.4 proc structure after patch 2536 has
+		been installed may need -DPIOMEMOPS.  So lsof's
+		MkKernOpts script was updated to propagate that
+		option from CCOPTS in /var/sysgen/system/irix.sm,
+		even though patch 2536 doesn't add -DPIOMEMOPS to
+		it.  Added a 00FAQ item on this patch.
+
+		Added a fatal warning message about names forced
+		to be file system names (with +f) that have no
+		match in the mount table.
+
+		Improved the -V message for files and file systems
+		for which no open files were found.  Added reporting
+		of /proc file and file system search failures.
+
+		Did some code reorganization to combine the multiple
+		ck_file_arg() functions into one.  Moved the new
+		function from the library to the top level and put
+		it in arg.c; moved the usage function from arg.c
+		to a new top-level source file, usage.c, to balance
+		top-level source file size.  The new usage.c depends
+		on version.h; arg.c no longer does.
+
+		Added flag recommended by the DU compiler for the
+		updated (and longer) main.c.
+
+4.27		March 6, 1998
+		At the request of Igor Schein <ischein@air-boston.com>
+		added a conditional repeat mode option, using the
+		`+' prefix to the `r' option.  +r operates as does
+		-r with the exception that it exits the first time
+		no open files have been listed during a cycle.
+		The exit code will be zero when any open files have
+		been listed; one, if none were ever listed.
+
+		Ported lsof to HP-UX 11.0 with the help of Richard
+		Allen.  This port hasn't been tested on a 64 bit
+		kernel; I'm sure it won't work there without more
+		mods.  It may not work on PA 2 architectures; I've
+		only tested it under PA 1 and a separate, busy
+		tester reported PA 2 problems that I've been unable
+		to investigate.
+
+		In anticipation of getting access to a 64 bit HP-UX
+		kernel and the pending start of the Solaris 2.7
+		Beta test (It will have 64 bit kernel addressing.),
+		started adding support for 64 bit kernel pointers.
+		This includes: ubiquitous use of the KA_T cast
+		for kernel pointers; a format to print them,
+		KA_T_FMT_X; a function to print them, print_kptr();
+		and modifications to most kernel-related functions
+		-- e.g., process_file(), process_node(),
+		process_socket(), readvfs() -- to process kernel
+		addresses as KA_T types.
+
+		Fixed minor bug in handling path name arguments
+		that end with a `/'.
+
+		Removed support for RISC/os; its test system is no
+		longer available.
+
+		Made modifications to insure that lsof output
+		doesn't contain non-printable characters.  All such
+		characters are now printed in the printf form
+		"\x%02x".  Several new common functions were
+		installed in misc.c to support "safe" printing.
+		This second major modification in 4.27 to common
+		and dialect code could have introduced bugs not
+		yet detected.
+
+4.28		March 10, 1998
+		Refined unprintable format to use \b, \f, \r, \n,
+		\t, and ^* (for CTRL) forms.  Corrected omission
+		of safestrprt() use for field output command name.
+		These changes were offered as patches to 4.27.
+
+		Made space an unprintable character (\x20) in the
+		COMMAND column; printable elsewhere, including the
+		NAME column, field output, and error messages.
+
+		Made sure FD column is parseable as a single entity
+		-- i.e., has no embedded space.  Thus, if the access
+		mode is unknown but there is a known lock mode, (a
+		very rare case) the access mode will be printed as
+		`-'.
+
+		Picked lint with gcc 2.8.0 under Solaris 2.6.
+
+		With the help of Dave Olson of SGI identified a
+		proc struct element that should have been added to
+		<sys/proc.h> by IRIX 6.4 patch 2536.  Added a
+		work-around for it to the lsof Configure script.
+		Igor Schein <ischein@air-boston.com> identified
+		that the patch caused a proc structure length
+		complaint from lsof.  Removed an obsolete 00FAQ
+		item on the patch, installed at lsof 4.26, explaining
+		that no solution was yet available.
+
+		Added a 00FAQ item on how BIND installs its own
+		header files, including <netdb.h>, which may cause
+		the rpcent struct definition to vanish.  Solaris
+		has an automatic lsof work-around, but that hasn't
+		been (and probably can't be) propagated to all
+		dialects supported by lsof.  The 00FAQ item recommends
+		re-installation of the vendor header files that
+		BIND has replaced.  (Others include <rpcent.h>,
+		<sys/bitypes.h>, and <sys/ctypes.h>.)
+
+		Made AIX AFS fixes.
+
+4.29		March 26, 1998
+		Corrected bug in Internet address matching.  The
+		matching formerly stopped if the foreign address
+		matched, thus failing to check the local address
+		for a match.  That led to a possible false "Internet
+		address not located" warning (i.e., in response to
+		-V) about the local address, when both foreign and
+		local addresses were specified with -i.  This
+		correction was offered as a patch to 4.28.
+
+		Changed readmnt() usage in an attempt to defer
+		mount readlink() and stat() delays until they are
+		necessary.
+
+		Corrected two bugs in the Digital UNIX readdev()
+		function.  Made the correction available as a patch
+		to 4.28 and regenerated the 4.28 DU binaries.
+
+		Added a missing argument to a print-kptr() call in
+		the HP-UX dsock.c.  The missing argument causes a
+		fatal gcc error.  The problem was reported by Eyal
+		Shaynis <eyal.shaynis@telrad.co.il>.  The fix was
+		offered as a 4.28 patch.
+
+		Adjusted for Digital UNIX 4.0D; the spec_node
+		structure is now defined in <sys/specdev.h>.  Kris
+		Chandrasekhar <Kris.Chandrasekhar@digital.com>
+		identified the need for the adjustment.
+
+		Incorporated a bug fix from Brian McAllister
+		<mcallister@mit.edu> to the DU readmnt() function.
+		This fix was offered as a patch to 4.28.
+
+		Added "safe" printing to a SunOS clone device error
+		message.
+
+		Corrected bug in tabling of Linux /proc-based lock
+		info.
+
+		Corrected bug in handling of SunOS TLI streams.
+		Dan Farmer <zen@trouble.org> reported the problem.
+
+		Added a Solaris 2.6 work-around to keep the BIND
+		<sys/bitypes.h> from colliding with the Solaris
+		<sys/int_types.h>.
+
+		Strengthened the Configure test for /proc-based
+		Linux lsof, based on a report from Marty Leisner
+		<leisner@sdsp.mc.xerox.com>.
+
+		Tested on OpenBSD 2.3.
+
+		Made AIX changes that allow use with 3.2.5.  The
+		changes were suggested and tested by Brett Hogden
+		<hogden@rge.com>.
+
+		Added Solaris 2.6 AFS support.  Disabled reporting
+		of some node numbers for Solaris 2.5 and above open
+		AFS files.  The node number computation algorithms
+		used for SunOS 4.1.x and Solaris less than 2.5 no
+		longer always work under Solaris 2.5 and above.
+
+4.30		April 9, 1998
+		Corrected a pid structure member naming error for
+		UnixWare < 2.1.2.  The problem was reported by
+		Richard van Meurs <vanmeurs.anva@atriserv.nl>.  He
+		supplied the correction.  This was offered as a
+		patch to 4.29.
+
+		Had a report from Igor Schein <ischein@air-boston.com>
+		that IRIX 6.4 patch 2839 is another SGI kernel
+		patch, along with 2536, that changes the size of
+		the proc structure in the kernel without changing
+		the proc structure in <sys/proc.h>.  Upon further
+		investigation found that the effect of these patches
+		on the proc structure is not consistent.  Therefore,
+		dropped the Configure patch test for IRIX 6.4 and
+		made the code in irix/dproc.c slightly more tolerant
+		of proc structure size differences for IRIX 6.4.
+		Igor help test the change.
+
+		Corrected Solaris >= 2.5 AFS inode number generation.
+		Craig Everhart <Craig_Everhart@transarc.com> helped
+		find the cause of the problem.  This was offered as
+		a patch to 4.29.
+
+		Refined the Linux /dev/kmem-based glibc evasion
+		for the timeval structure to make it work with
+		glibc version 2.0.7.  This required defining a new
+		global symbol, TIMEVAL_LSOF, default timeval, that
+		the /dev/kmem-based Linux lsof can set to its
+		private glibc timeval name, distinct from the kernel
+		timeval name.
+
+		Added support for Alpha to the /dev/kmem-based
+		Linux lsof.  Alexandre Oliva <oliva@dcc.unicamp.br>
+		provided a test system.  Added an item to 00FAQ
+		about lsof, the Alpha processor, and Linux.
+
+		Added a 00FAQ item about lsof year 2000 compliance.
+		Basically it says lsof is probably compliant,
+		because its only date or time computations are done
+		with time_t values, but I haven't done any specific
+		Y2K validation.  I don't have plans to do any.
+
+		Added support for UnixWare 7.  Chris Daniels
+		<chrisd@dlpco.com> provided a test system and Don
+		Draper <dond@sco.COM> provided technical information.
+		Added BFS and SFS file system support to lsof for
+		UW 2.1.[12] and 7.
+
+		Updated Solaris VxFS support for VxFS 3.2.1.  Greg
+		Earle <earle@netbsd4me.jpl.nasa.gov> reported the
+		need for the update.  Greg and Roger Klorese
+		<rogerk@veritas.com> provided technical information.
+		Scott McClung <mcclung@primenet.com> tested.
+
+		Changed IRIX XFS patch detection in anticipation of
+		learning there are multiple XFS patches for IRIX 6.4
+		that require different versions of the lsof-invented
+		xfs_inode structure.
+
+4.31		April 21, 1998
+		Added a VxFS #if/#endif wrap to a section of the
+		HP-UX dnode.c that wasn't properly protected.  The
+		problem was reported by  Peter Klosky <PKlosky@bdm.com>.
+		This was offered as a patch to 4.30.
+
+		Added support for Solaris 2.7 (first Beta release).
+		Mike Sullivan <Mike.Sullivan@Eng.Sun.COM> provided
+		technical advice and helped test.  Charles Stephens
+		<cfs@jurassic.eng.Sun.COM> also helped test.
+
+		Fixed bug in /proc-based Linux that caused it to
+		access /proc/mounts excessively.  Marty Leisner
+		<leisner@sdsp.mc.xerox.com> provided a syscall
+		trace that identified the bug.  The fix was offered
+		as a patch to 4.30.
+
+		Adjusted the IRIX 6.4 private structure definition
+		for the XFS node to accommodate patch 2970.  Igor
+		Schein <ischein@air-boston.com> identified the
+		patch and the required adjustment.
+	
+4.32		May 11, 1998
+		Corrected Solaris 2.7 code for reporting PCFS
+		(floppy disk) node numbers.  Casper Dik
+		<casper@holland.sun.com> supplied the fix.  The
+		fix was offered as a patch to 4.31.
+
+		Corrected a bug in conditional repeat mode handling
+		pointed out by Igor Schein <ischein@air-boston.com>.
+		This was offered as a patch to 4.31.
+
+		Improved reporting of AIX open(/dev/memory device)
+		errors.
+
+		Corrected a Solaris < 2.5 KA_T declaration error,
+		pointed out by Robert Kiessling <robert@easynet.de>.
+		Changed KA_T from a #define to a typedef for all
+		dialects to prevent future problems of this kind.
+
+		Changed the sample Perl 5 script big_brother.perl5
+		to report a four digit year from localtime().
+
+		Added support for AIX 4.3[.1].  Bill Pemberton
+		<wfp5p@tigger.itc.virginia.edu> provided a test
+		system.  Andrew Kephart <akephart@austin.ibm.com>
+		and Tom Weaver <tvweaver@austin.ibm.com> provided
+		technical assistance.  Niklas Edmundsson
+		<nikke@ing.umu.se> did 4.3.1 testing.
+
+		Added -qmaxmem option to CFLAGs for an AIX compilation
+		with an xlc version 4.x compiler.
+
+		Adjusted Linux socket handling for changes in the
+		AX25 members of the sock struct.   Richard Green
+		<rtg@tir.com> pointed out the problem.  Tested
+		/dev/kmem-based lsof under Linux 2.0.34.
+
+4.33		May 22, 1998
+		Added generic IPv6 support to common lsof sources
+		and specific IPv6 support to AIX sources.  Andrew
+		Kephart <akephart@austin.ibm.com> supplied the
+		additions and helped with testing.  Bill Pemberton
+		<wfp5p@tigger.itc.virginia.edu> provided a test
+		system.  The modification affected sources for
+		every dialect, whether it supports IPv6 or not, by
+		changing the interfaces to the common Internet
+		address function ent_inaddr().
+
+		Added support for the NetBSD UVM virtual memory
+		system.  Paul Kranenburg <pk@cs.few.eur.nl> supplied
+		technical details.
+
+		Bracketed HP-UX 11 use of <sys/spinlock.h> with
+		#if/#endif _KERNEL.
+
+		Corrected printing of PCB address in DEVICE column
+		for IRIX.
+
+4.34		June 26, 1998
+		Updated 00FAQ to discuss TCP and UDP ports private
+		to the AIX kernel and 00README to describe how ACLs
+		can be used to give lsof permission to read the
+		kernel memory devices.  Add information to 00FAQ
+		and 00README about other OpenBSD architectures
+		where lsof is reported to compile and run.  Added
+		section to 00FAQ discussing how an incorrect loader
+		path environment variable value can prevent lsof
+		from loading correctly.
+
+		Improved Solaris namefs and doorfs support so that
+		it is now possible to search for an open VDOOR file
+		by the path name of its fattached file system
+		object.  Igor Schein <igor@txc.com> requested the
+		ability to do such a search.  Even with the change,
+		lsof can't always identify path names for open
+		VDOOR files.
+
+		Also at Igor's request, improved reporting of
+		information on open Solaris VCHR files that share
+		a common vnode, and Solaris UNIX domain socket
+		files.
+
+		Corrected print_kptr() argument error in PTX dnode.c,
+		reported by Mark Price <mprice@sequent.com>.
+		Compensated for ncache element naming differences,
+		introduced at PTX 4.4.2; Kurtis D. Rader
+		<krader@sequent.com> reported the problem.
+
+		Changed output column title from INODE to NODE to
+		better reflect the column's contents of node IDs
+		for more than just inodes.
+
+		Improved Configuration and processing for Solaris
+		AFS.  Corrected AIX AFS 3.4 afs_rwlock_t simulation.
+
+		Corrected a cast problem with two AIX knlist()
+		calls, thus quieting an AIX 4.2.1 compiler argument
+		type warning.  Jon Champlin <champlin@us.ibm.com>
+		reported the problem.
+
+		Added support to most dialect versions (exception:
+		/proc-based Linux) to warn when the identity of
+		the kernel where lsof was compiled doesn't match
+		the running identity.  The warning can be suppressed
+		with -w.  Note: determining AIX state requires
+		calling oslevel, a potentially slow operation.
+		Jon Champlin <champlin@us.ibm.com> suggested this
+		addition.
+
+	!!!! WARNING !!!!    !!!! WARNING !!!!    !!!! WARNING !!!!
+
+		Those using the lsof cross-configuration capability
+		(see 00XCONFIG), should be aware that the kernel
+		identity test feature introduces two new basic
+		cross configuration environment variables, LSOF_ARCH
+		and LSOF_VSTR.
+
+	!!!! WARNING !!!!    !!!! WARNING !!!!    !!!! WARNING !!!!
+
+		Identified a situation where a Solaris UNIX domain
+		socket name is known and can be searched for by
+		name; added the necessary code.
+
+4.35		July 17, 1998
+		Made the kernel identity check an option with the
+		HASKERNIDCK #define in machine.h.  Enabled altering
+		of HASKERNIDCK with the Customize script.  Added
+		a clause to the help output that indicates the
+		build-time HASKERNIDCK status.
+
+		Added more information to the NAME column for
+		Solaris UNIX domain sockets.  Made them searchable
+		by their clone device path name.  Igor Schein
+		<igor@txc.com> requested this.
+
+		Completed the HP-UX 11 port with support for its
+		optional 64 bit kernel.  Rich Rauenzahn
+		<rrauenza@cup.hp.com> provided a test system.
+		Corrected errors with HP-UX 11 lock reporting and
+		private kernel structure and type definitions.
+		Added support for HP-UX NFS3 files.
+
+		Limited mount table warnings -- e.g., when -b is
+		used -- to one set per mount point.
+
+		Fixed some mount table scanning and usage bugs,
+		including one in Solaris, reported by Kjetil Torgrim
+		Homme <kjetilho@ifi.uio.no>.
+
+4.36		August 4, 1998
+		Made corrections and additions to IPv6 support and
+		to AF_ROUTE socket handling, supplied by Jean-Luc
+		Richier <Jean-Luc.Richier@imag.fr>.  Jean-Luc's
+		additions provide IPv6 support for the Inria IPv6
+		implementations on FreeBSD and NetBSD.
+
+		Fixed two Solaris 2.5, 2.5.1, 2.6 and 2.7 TCP and
+		UDP host name or IP address reporting bugs, reported
+		by James Mathiesen <James-Mathiesen@deshaw.com>.
+		This fix was offered as a patch to 4.35.
+
+		Updated the Customize script to cause ENTER to use
+		all defaults.  Amir J. Katz <amir@ndsoft.com>
+		suggested this and helped test the changes.
+
+		Updated Solaris ICMP and IP stream handling, based
+		on a report from Igor Schein <igor@txc.com>.
+
+		Fixed a bug in the Digital UNIX mount table handling,
+		reported by Bob Ward <bward@thehartford.com>.
+		While working on the bug, found and updated some
+		obsolete AdvFS code.  This fix was offered as a
+		patch to 4.35.
+
+4.37		September 15, 1998
+		Deactivated SGI IRIX support and archived revision
+		4.36 sources and binaries in pub/tools/unix/lsof/OLD.
+
+		Improved performance of FD searching.  This was
+		offered as a patch to 4.36.
+
+		Amir J. Katz <amir@ndsoft.com> pointed out that
+		ranlib isn't needed for AIX or Solaris.  Made
+		appropriate Configure script changes.
+
+		Fixed a file offset reporting bug for HP-UX VCHR
+		and VBLK device nodes located on a VxFS root.  Doug
+		Siebert <douglas-siebert@iowa.edu> reported the
+		bug.  The fix was offered as a patch to 4.36.
+
+		Resolved an HP-UX root device name reporting bug,
+		partly caused by an out-dated local copy of the
+		<sys/mount.h> mount structure, by generating a
+		local header file with the structure that can be
+		compiled without needing _KERNEL defined.  Doug
+		Siebert also reported this bug.
+
+		Changed some dialect source code -- Digital UNIX,
+		Solaris, SunOS, and UnixWare -- to make more
+		consistent with ps the user ID lsof reports in the
+		USER column.  Added a 00FAQ entry about it.  Igor
+		Schein <igor@txc.com> reported the Solaris and
+		SunOS lsof inconsistencies with what ps(1) reports.
+
+		Ported lsof to Pyramid ReliantUNIX 5.44.
+
+		Added brackets as comments to case, do, done, else,
+		endif, esac, if, and while statements in Configure
+		to assist in navigating its clauses.
+
+		Added more Linux 2.0.x glibc work-arounds.
+
+		Added support for UnixWare 7.0.1.
+
+		Ralph Forsythe <ralph@contact-paging.com> provided
+		a new FreeBSD test system.
+
+4.38		November 25, 1998
+		Added support for recent FreeBSD 3.0 distributions.
+		A 3.0 test system was provided by David O'Brien
+		<obrien@NUXI.com>.  This was offered as a patch
+		to 4.37.
+
+		Updated the scripts/idrlogin.perl* files to look
+		for sshd processes in addition to rlogind and
+		telnetd ones.
+
+		Added support for DU 5.0 Beta.  Berkley Shands
+		<berkley@cs.wustl.edu> provided a test system.
+
+		Added support for OpenBSD 2.4 with changes supplied
+		by Kenneth Stailey <kstailey@disclosure.com>.
+
+		Changed the Solaris 2.7 tests and documentation to
+		Solaris 7.
+
+		Made some changes to the header files for NEXTSTEP
+		3.3 and added support for OPENSTEP 4.x with help
+		from Michael A. Hovan III <mhovan@BLaCKSMITH.com>
+		and Carl Lindberg <Carl_Lindberg@BLaCKSMITH.com>.
+		The combined dialect subdirectory is named n+os.
+		One of Carl's changes propagates RC_CFLAGS to the
+		library Makefile.  Timothy J. Luoma <luomat@peak.org>
+		helped test under NEXTSTEP 3.3 and OPENSTEP 4.2.
+
+		Made UW 7.x version sensitive to the presence of
+		ptf7038.  Added peer PCB address to Unix domain
+		socket Name column, even when a path name has been
+		located.  Information for these changes was supplied
+		by Francis Le Bourse <flebourse@intelcom.fr>.  Lee
+		Penn <lee@dlpco.com> provided a test system.
+
+		Tested lsof under OSR 5.0.5 on a test system also
+		provided by Lee Penn.
+
+		Made path name argument processing more tolerant
+		of errors per a suggestion from Julian Gordon
+		<julian@cadence.com>.
+
+		Acquired a new UnixWare 2.x test system, generously
+		provided by Computer Classroom, Inc. -- Matthew
+		Thurmaier <matt@compclass.com>, Ken Laing
+		<ken@compclass.com>, and Andrew Merril
+		<andrew@compclass.com>. Updated Configure to accept
+		a UnixWare version of 2.1.3.
+
+		Updated kmem-based lsof for Linux 2.0.36.
+
+		Updated NetBSD sources for a change in a UVM virtual
+		mapping header file.
+
+		Corrected a cache allocation bug in Sun format
+		kernel name cache handling.  The bug only shows up
+		when the kernel name cache is inaccessible.
+
+4.39		December 29, 1998
+		Corrected problems with large device number handling
+		for 64 bit Solaris 7.  The problems were reported
+		by Steve Bellenot <bellenot@math.fsu.edu>.  Steve
+		helped test the fixes.  The fixes were offered as
+		two patches to lsof 4.38.
+
+		Improved FreeBSD Configure operations for header
+		files that must be obtained from the kernel source
+		tree, based on a suggestion from David O'Brien
+		<obrien@NUXI.com>.
+
+		For Bela Lubkin <filbo@deepthought.armory.com> made
+		optional with +f[cfn] the display of file structure
+		address, shared use count, and node structure
+		address.  /proc-based Linux doesn't implement this
+		feature, because it doesn't read kernel structures
+		from kernel memory.  Modified the PTX -X option to
+		take advantage of the new file structure display
+		option.  Added shared.perl5 to the scripts/
+		subdirectory to provide an example of how +f[fn]
+		might be used to track shared file descriptors and
+		files.
+
+		Added more /dev/kmem-based Linux glibc evasions,
+		provided by Jeff Johnson <jbj@redhat.com> and Maciej
+		Lesniewski <nimir@kis.p.lodz.pl>.  Jeff helped test
+		them on various Linux architectures.
+
+		Tested on AIX 4.3.2; no changes were required.
+		Doug Crabill <dgc@purdue.edu> provided a test
+		system.
+
+		Fixed -c option to detect missing command name when
+		following option begins with `+'.
+
+4.40		January 25, 1999
+		Added support for using the CDS compiler for Reliant
+		Unix 5.44 and above.  Made Reliant Unix MIPC support
+		optional, dependent on the presence of <sys/mipc.h>.
+
+		Based on a report from Michael Schmitz <MSchmitz@lbl.gov>
+		that /dev/kmem-based lsof misbehaves on a Linux
+		2.0.x m68k kernel without module support, made the
+		absence of query_module() or get_kernel_syms()
+		Linux kernel support a fatal error.  Updated relevant
+		sections of 00FAQ to reflect the change.
+
+		Added the ability to force the Linux Configure
+		stanza to use the /proc or /dev/kmem source base
+		via a LINUX_BASE environment variable specification.
+		This is a cross-configuration assist.
+
+		Added "+D <dir>" and "+d <dir>" options for directory
+		searching.  +D searches the entire tree, starting
+		at <dir>, including <dir>, its contents, and its
+		subdirectory branches; +d searches only <dir> and
+		its contents, but not its subdirectory branches.
+		Improved lsof's searching of the specified name
+		list to compensate for anticipated long lists from
+		+d and +D.
+
+		Made an egrep in the Solaris Configure stanza usable
+		by the standard and XPG4 egrep's.  Kenneth Stailey
+		<kstailey@disclosure.com> pointed out the improvement.
+
+		Fixed bugs in /dev/kmem-based Linux and UnixWare
+		Unix domain socket name searching.
+
+		Changed a Linux Alpha #include to be conditional
+		on the presence of its named header file, so that
+		lsof will compile on Red Hat 5.1 and 5.2 (Linux
+		kernel 2.0.35) where the header file is absent.
+		The problem was reported by Alexandre Oliva
+		<oliva@dcc.unicamp.br>.
+
+		Fixed an AIX 4.3+ bug in procinfo struct space
+		allocation, reported by Jeff Stewart <jws@purdue.edu>.
+		This was offered as a patch to 4.39.
+
+		Added an lstatsafely() function to offer the same
+		isolation for lstat() calls that statsafely() offers
+		for stat() calls.  This made DOSTAT_FUNCTION no
+		longer necessary, so deleted it.
+
+		With help from Laurent P. Montaron <lpm@sequent.com>
+		ported lsof to PTX 4.4.4.  Laurent did a monumental
+		job of identifying TCP/IP changes by their TCP
+		version, rather than by their PTX (With mix 'n
+		match PTX and TCP/IP versions, the PTX version
+		often has no bearing on the TCP/IP version.), and
+		changed the Configure script and pre-processor
+		#if/#else/#endif blocks to match.  He also updated
+		Unix domain socket handling for PTX TCP/IP versions
+		4.5 and above.
+
+		Updated CLIENT handle acquisition of fill_portmap()
+		in print.c to use the more modern RPC function
+		clnt_create() in place of clnttcp_create() where
+		possible.  PTX 4.4.4 requires clnt_create().
+
+4.41		February 27, 1999
+		Added FreeBSD 3.1 and and 4.0 support with help
+		from Sheldon Hearn <axl@iafrica.com>, David O'Brien
+		<obrien@NUXI.com>, and John Polstra <jdp@polstra.com>.
+
+		Corrected bungled AIX 4.3+ patch that went into
+		lsof 4.40.
+
+		Reorganized the Configure script to improve Makefile
+		construction.  A specific impetus for this was to
+		allow FreeBSD system-wide make flags to be propagated
+		to the lsof Makefiles, but other goals were to make
+		sure that the DEBUG= make entry can over-ride
+		standard CFLAGS values, and to better manage the
+		identification of compilers and their versions.
+		Two compiler-related values may now be supplied in
+		environment variables: 1) the compiler path in
+		LSOF_CC; and 2) the compiler version in LSOF_CCV.
+		00XCONFIG documents them.
+
+		Added support for Pyramid Reliant Unix bsdsfs,
+		msockfs, and sockfs file systems.
+
+		Added an optional LSOF_CINFO string to Configure,
+		producing a CINFO string in selected Makefiles,
+		producing a #define LSOF_CINFO in selected version.h
+		header files.  The purpose of this is to allow
+		Configure the option to propagate information to
+		the lsof -v output.  It is now used for Linux to
+		identify the code base, and for HP-UX 10.30 and
+		11.0 and Solaris 7 to identify the kernel bit size.
+
+		Added system information to NEXTSTEP and OPENSTEP
+		-v output, from the second line of hostinfo's
+		output.
+
+		Fixed a login name buffer overflow problem in the
+		processing of -u option values.  This was offered
+		as a patch to 4.40.  !!!THIS IS A SERIOUS STACK
+		OVERFLOW BUG; A LINUX EXPLOIT EXISTS FOR IT THAT
+		OPENS A BASH SHELL WITH LSOF'S AUTHORITY -- E.G,
+		SETGID(KMEM) POWER!!!
+
+		Improved the Solaris mount table filter so the
+		volume manager's fake mount point, "/vol", is
+		ignored and doesn't supplant "/" in NAME column
+		path assemblies.  Igor Schein <igor@txc.com> reported
+		this bug and provided important help in finding
+		it.  This was offered as a patch to 4.40.
+
+		Changed the Linux /dev/kmem-based lock ownership
+		test to answer a problem reported by Tom Christiansen
+		<tchrist@jhereg.perl.com>.  This was offered as a
+		patch to 4.40.
+
+		Installed an HP-UX 11 patch, suggested by Kevin
+		Vajk <kvajk@cup.hp.com>, that adjusts a private
+		lsof kernel header file, derived via Q4, to correspond
+		to an HP-UX patch bundle.
+
+		Made NetBSD 1.3I sockproto structure adjustment.
+
+4.42		March 30, 1999
+		Fixed a typo in the HP-UX dfile.c that caused +fF
+		and +fN output controls to swap effect.
+
+		Enabled for OpenBSD 2.5 per notice from Kenneth
+		Stailey <kstailey@kstailey.tzo.com>
+
+		Made more VM accommodations for FreeBSD 4.0.
+
+		Improved file system search reporting to include
+		path name components when they're available, instead
+		of mindlessly reporting the file system name in
+		the NAME column.  Guy Dallaire <gdallair@geocities.com>
+		brought the need for this change to my attention.
+
+		Updated Solaris 2.6 VxFS for Veritas Oracle Database
+		Edition 2.0, VxFS version 3.3, and VxVm version
+		2.5.4, based on a report from Chris Kordish
+		<chris.kordish@East.Sun.COM>.  Chris kindly provided
+		a test system.
+
+		Improved HP-UX ipc_s patch detection in Configure,
+		response in .../dialects/hpux/hpux11/ipc_s.h, and
+		documentation in 00FAQ, Kevin Vajk <kvajk@cup.hp.com>
+		helped test.
+
+		Added to Customize the option to suppress HASKERNIDCK
+		selection for specified dialects.  Suppressed it
+		for /proc-based Linux lsof, and removed its test
+		and code from there.  Tin Le <tin@netimages.com>
+		alerted me to the need for this update.
+
+		Ported to official Digital UNIX 5.0 release.
+
+		Changed DU lsof to use the knlist(3) function when
+		no kernel file has been specified with -k.  This
+		change was suggested by Erich Wimmer
+		<Erich.Wimmer@digital.com>.
+
+		Updated Configure for latest NetBSD (1.3I?) with
+		UVM support the default.
+
+4.43		May 11, 1999
+		Corrected a typo in the Solaris gcc discussion in
+		00FAQ.  Made changes to the Solaris 2.5[.1] private
+		tcp_s structure.  Both changes were done in response
+		to reports from Igor Schein <igor@txc.com>, who
+		tested the Solaris 2.5 change.
+
+		Made more IPv6 adjustments to lsof for Tru64 UNIX
+		(Digital UNIX) 5.0, based on information obtained
+		from Compaq by Berkley Shands <berkley@cs.wustl.edu>.
+
+		Corrected HP-UX error message about HP-UX 11 q4 usage.
+		Amir Katz <amir@ndsoft.com> reported the correction.
+
+		Fixed a GlibC 2.1 conflict in /proc-based Linux lsof.
+
+		Fixed a man page typo reported by Vlad Harchev
+		<hvv@hippo.ru>.
+
+		Changed some Solaris 2.7 references to Solaris 7
+		in Configure and 00XPORTING.
+
+		Added a Solaris example to the echo statements that
+		are the install rule in the SunOS/Solaris Makefile.
+
+		Added a field to the file structure output --
+		FILE-FLAG (file structure open flags, f_flag[s],
+		and process file flags, typically u_pofile)) --
+		enabled with +f[gG].  Its field output character
+		is 'G'.
+
+		Figured out another piece of the HP-UX 11 patched
+		ipc_s structure puzzle with the help of Keith Kalet
+		<KEITH_KALET@HP-USA-om41.om.hp.com>.
+
+		Fixed a PTX real vnode to real inode interpretation
+		bug.
+
+		Added link count to lsof output.  Eric Dumazet
+		<dumazet@risgw.ris.fr> requested and helped test
+		it.  The new +L option enables and filters it.
+		Its field output character is `k'.
+
+		Updated Configure script to recognize NetBSD 1.4.
+
+		Updated AFSConfig to handle default answers to
+		questions.
+
+		Incorporated patch from Jonathan Sergent <sergent@io.com>
+		that enables /proc-based Linux lsof to run on both
+		32 and 64 bit kernels.
+
+		Updated Configure script with a patch from David
+		O'Brien <obrien@NUXI.com> that recognizes FreeBSD 3.2.
+
+4.44		June 24, 1999
+		Corrected use of nlink member of hsnode for SunOS
+		4.1.x High Sierra File System files.  John Dzubera
+		<zube@tlaloc.stat.colostate.edu> reported the
+		problem and helped test the fix.  Also fixed a
+		SunOS segmentation fault bug.  These fixes were
+		offered as a patch to 4.43.
+
+		Improved handling of /proc-based Linux UNIX PCB
+		address.
+
+		Fixed a NEXTSTEP and OPENSTEP bug that made repeat
+		option (-r) processing malfunction.  This fix was
+		offered as a patch to 4.43.
+
+		Fixed Configure so it doesn't use -O in the Cflags
+		for the bundled HP-UX C compiler.  Jim Ankenbrandt
+		<jankenbrandt@penton.com> reported the problem.
+
+		Corrected output ordering of parent PID and process
+		group ID when both -R and -g are specified.
+
+		Enhanced the pdev.c and pdvn.c library modules for
+		wider use.  These dialect versions use the new
+		library modules: DEC OSF/1, Digital UNIX, and Tru64
+		UNIX; Pyramid DC/OSx and Reliant UNIX; SCO OSR and
+		UnixWare; and Sequent PTX.
+
+		Added basic clone device support to /dev/kmem-based
+		HP-UX lsof for HP-UX 10.30 and higher.
+
+		Added raw socket support to /proc-based Linux lsof.
+
+		Changed NODE-ADDR column title to NODE-ID in
+		anticipation of using more general identification
+		information in the column.
+
+		Ported to UnixWare 7.1, using a test system kindly
+		provided by Matt Thurmaier <matt@compclass.com>
+		and Don Draper <dond@sco.com>.
+
+		Updated for NetBSD 1.4C VM changes, and a new
+		current and root working directory structure.
+
+		Made minor adjustment for latest Tru64 UNIX 5.0
+		Beta release.
+
+4.45		July 30, 1999
+		Fixed quoting problem in DEC OSF/1, Digital Unix,
+		and Tru64 UNIX Makefile's install rule.  The problem
+		was reported by Berkley Shands <berkley@cs.wustl.edu>.
+		Fixed bug in Tru64 UNIX 4 lsof that caused FDs to
+		be skipped.  These fixes were offered in a patch
+		to 4.44.
+
+		Fixed a repeat-mode /proc-based Linux lsof bug,
+		reported by Sami Farin <sfarin@ratol.fi>.  This
+		was offered as a patch to 4.44.
+
+		Picked lint, some reported by Sami Farin.
+
+		Corrected a 00DCACHE documentation error in a sample
+		shell script.  The problem was reported by Chad R.
+		Larson <chad@larsons.org>.  Changed commented-out
+		entries in machine.h files so they require more
+		thought and work when the comments are removed,
+		based on a remark by Chad.
+
+		Compensated for the practice of Solaris 7 and above
+		to record the dev= value in /etc/mnttab in 32 bit
+		mode, even on 64 bit systems.  This was offered as
+		a patch to 4.44.
+
+		Added a C library test for /proc-based Linux lsof,
+		so that the #include files can be adjusted for a
+		non-GlibC environment.  The need for this was
+		reported by Andrew Hill <andrewh@tirin.openworld.co.uk>.
+		This was offered as a patch to 4.44.
+
+		Added support for Auspex LFS 1.8.1 and 1.9.2 to
+		SunOS 4.1.4 lsof.  The support was requested by
+		Quentin Fennessy <quentin@dvorak.amd.com>, who
+		provided information and did testing.
+
+		Enabled IPv6 support code for NetBSD and OpenBSD,
+		conditional on Configure script tests.  Wolfgang
+		Rupprecht <wolfgang@wsrcc.com> supplied the NetBSD
+		code and tested it.  The OpenBSD code I constructed
+		has been compiled but not tested.
+
+		Updated the identd Perl 5 script, based on a report
+		from Wendy Lin <af5@taiyang.cc.purdue.edu> that
+		the space in its response line in front of the user
+		name violates RFC 1413.
+
+		Added IPv6 support to /proc-based Linux lsof.
+		Jonathan Sergent <sergent@ETLA.NET> and Andrew
+		Thomas Sydelko <sydelko@ecn.purdue.edu> kindly
+		provided a test system.
+
+		Updated man page description of AIX multiplexed
+		files to indicate that they might be /dev/ptc or
+		/dev/pts, depending on the AIX version.  The
+		correction was suggested by Onno van der Linden
+		<onno@simplex.nl>.
+
+		Sylvain Robitaille <syl@alcor.concordia.ca> reports
+		lsof passes his Y2K tests.
+
+4.46		October 23, 1999
+		Corrected /proc-based Linux lsof to detect that an
+		IPv6 address is a mapped IPv4 address.  The problem
+		was reported and analyzed by Arkadiusz Miskiewicz
+		<misiek@misiek.eu.org>, who also tested the fix.
+
+		Added a libc5 library /dev/kmem-based Linux lsof
+		circumvention, supplied by Jason Lingohr
+		<lingman@lucid.net.au>.
+
+		Corrected a bug in -t (terse) AIX output, reported
+		by Wendy Lin <af5@taiyang.cc.purdue.edu>.  I
+		introduced the bug at revision 4.43 when adding
+		FILE_FLAG reporting.  This was offered as a patch
+		to 4.45.
+
+		Added a work-around for a problem in the OpenBSD
+		2.3 <sys/pipe.h> header file.  Volker Borchert
+		<bt@teknon.de> provided and tested it.
+
+		Improved description of cross-building lsof for a
+		64 bit Solaris 7 system on a 32 bit system with
+		suggestions from Phillip Edwards
+		<Philip.Edwards@sn.wpafb.af.mil>.
+
+		Fixed a gawk POSIX-mode pattern error in the Linux
+		/dev/kmem-based Mksrc script, based on a tip from
+		Ambrose C. Li <acli@mingpaoxpress.com>.
+
+		Fixed a bug in the Tru64 UNIX IPv6 handling, courtesy
+		of a report from Casper Dik <casper@holland.sun.com>.
+
+		Enabled support for OpenBSD 2.6.
+
+		Enabled support for BSDI BSD/OS 4.1, based on a
+		report from Jeffrey C Honig <jch@bsdi.com> that
+		only a Configure script change is necessary.
+
+		Enabled Configure script to use gcc for building
+		lsof for a 64 bit Solaris 7 and 8 kernels, if the
+		gcc version is 2.95 or above.
+
+		Improved -i option handling for systems with IPv6
+		support so that it will search for a host name in
+		both IPv4 and IPv6 families, when that is possible.
+		As a companion modification, changed -V processing
+		to report a single error when a multiple host name
+		match is requested.  Casper Dik <casper@holland.Sun.COM>
+		helped test.
+
+		Fixed a DEC OSF/1, Digital UNIX, Tru64 UNIX repeat
+		mode bug, reported by Mayer Ilovitz <mayer@cooper.edu>.
+		Mayer helped test the fix.  The fix was offered as a
+		patch to 4.45.
+
+		Changed Solaris socket file recognition scheme, so it
+		is (nearly) the same through Solaris 8, where the
+		previous clone device scheme no longer works.
+
+		With significant assistance from Casper Dik, added
+		support for Solaris 8 Beta and Beta refresh.  The
+		IPv6 support in Solaris 8 is still in some flux,
+		so there are temporary compensations for the
+		differences between Beta IPv6 support and Beta
+		refresh IPv6 support.  Casper and I hope those
+		differences disappear by FCS.
+
+		Improved the delivery of information on Solaris
+		2.5.1, 2.6, 7, and 8 door files.
+
+		Fixed a repeat mode bug that surfaces when /etc/passwd
+		changes between cycles.  The bug report and diagnostic
+		help were supplied by Igor Schein <igor@txc.com>.
+		The fix was offered as a patch to 4.45.
+
+		Added support for INRIA IPv6 to NetBSD.  Jean-Luc
+		Richier <Jean-Luc.Richier@imag.fr> provided patches
+		and a test system on which to verify them.
+
+		Added support for AIX 4.3.3.  Jeff W. Stewart
+		<jws@anaconda.cc.purdue.edu> provided a test system.
+
+		Made adjustments for FreeBSD 4.0-current.
+
+		Improved reporting of information for AIX sockets that
+		lack protocol control blocks.
+
+4.47		November 29, 1999
+		Based on a query from Jean-Pierre Radley <jpr@jpr.com>,
+		changed the lsof top-level Makefile to propagate
+		CFGF to the library Makefile.  (DEBUG was already
+		being propagated.)  Added osrgcc and scogcc Configure
+		abbreviations (to use gcc) for Jean-Pierre.
+
+		In response to a query from Igor Schein <igor@txc.com>,
+		improved the Configure script test for Solaris 7
+		and 8 that decides if the compiler can produce 64
+		bit executables.
+
+		Made an ugly hack, based on making a private rnode
+		structure definition from q4 output, to compensate
+		for HP-UX 10.20 and lower recent NFS3 patches.  HP
+		didn't supply an updated <nfs/rnode.h> with the
+		patches.  The problem was reported by Will Partain
+		<partain@mekb2.sps.mot.com>.  Elias Halldor Agustsson
+		<elias@hi.is> helped identify the patches as
+		PHNE_18173, PHNE_19426, PHNE_19937, and PHNE_20091,
+		and provided a test system.
+
+		Switched BSDI test system from 2.1 and 3.1 to 4.0.1,
+		courtesy of Terry Kennedy <terry@tmk.com>.
+
+		Added some more dev_t hacks for Alpha FreeBSD 4.0.
+
+		Added support for IPv6 on BSD 4.x.  The support hasn't
+		yet been tested, just compiled.
+
+		Added support for the mnt file system (mntfs or
+		/etc/mnttab) on Solaris 8.  Tested on Solaris 8
+		BETA-Refresh.
+
+		Made selection of optional fields (e.g., PPID with
+		-FR) in a field output specification select the
+		optional field, too, so that the option selector
+		for the field (e.g., -R) isn't also required.  This
+		change was made in response to an inquiry from John
+		DuBois <spcecdt@armory.com>.  This may require some
+		revision to scripts that parse all field output;
+		two scripts in the lsof distribution's scripts/
+		subdirectory had to be updated.
+
+		Corrected handling of Linux IPv4 addresses mapped
+		in IPv6 addresses.
+
+		Tested under OpenBSD 2.6.
+
+4.48		January 14, 2000
+		Modified -i argument processing of colon-separated
+		IPv6 addresses to recognize an IPv4 address mapped
+		in an IPv6 address and handle it as an IPv4 address.
+		This was offered as a patch to 4.47.
+
+		Added a defined symbol (NOWARNBLKDEV) to control
+		(inhibit) the issuance of a warning when no block
+		devices are found.  This was done anticipating its
+		need in FreeBSD 4.x, but that dialect version no
+		longer has any block devices, so HASBLKDEV was
+		disabled for it instead.  NOWARNBLKDEV was left in
+		place for possible use in the future.
+
+		Enabled KAME IPv6 Configure support for FreeBSD
+		when <netinet6/in6.h> is found.
+
+		Disabled use of gcc to compile lsof for 64 bit
+		HP-UX 11.
+
+		Updated Configure to recognized FreeBSD 3.4.
+
+		Based on suggestions from Bernt Christandl
+		<beb@MPA-Garching.MPG.DE> improved AFS configuration
+		for AIX and Solaris, and updated AIX AFS 3.5 support.
+		Johannes Tax <tax@bluedog.oit.unc.edu>, Hung T.
+		Pham <hung_pham@unc.edu>, and Curt Freeland
+		<curt@grumpy.cse.nd.edu> provided test systems.
+
+		Updated lsof's private rnode definition for AIX
+		4.3.3, since IBM still doesn't ship the
+		<oncplus/nfs/rnode.h> header file and the rnode
+		structure definition in <nfs/rnode.h> doesn't match
+		what the kernel uses.  This was offered as a patch
+		to 4.47.
+
+		Weakened the test in the Linux /proc-based lsof of
+		the field count of data lines in /proc/net/{tcp,udp}.
+		It appears that recent 2.3.x Linux kernels have
+		added untitled fields to these files.  The bug
+		report came from Gabor Liptak <gaborliptak@usa.net>.
+
+		Adjusted for a FreeBSD 4.0 change in the definition
+		of [_]KERNEL.  David O'Brien <obrien@NUXI.com> reported
+		the problem and provided a test system.
+
+		Removed the HASPPID bracket from Fppid (the -R
+		option state variable) so that the field select
+		table will compile even when HASPPID is not defined.
+		This problem was introduced at revision 4.47 with
+		code that causes some field output characters to
+		set option states.  The problem was reported by
+		David Bacon <bacon@birch.eecs.lehigh.edu>.
+
+4.49		April 3, 2000
+		Made clearer in man page that "Lxx" FDs are AIX
+		loader table references.  Also updated the 00FAQ
+		discussion of the Stale Segment ID bug to include
+		AIX 4.3.x.
+
+		Modified support for NetBSD 1.4Q to include the
+		<sys/buf.h> header file to cope with an MFS change.
+
+		Added support for OpenBSD UVM virtual memory.
+
+		Added support for AIX systems with > 2GB of memory.
+		Chris Sylvain <csylvain@itg.ummc.umaryland.edu>
+		reported the problem and provided the solution.
+		Chris also supplied some minor code cleanup.  This
+		was offered as a patch to 4.48.
+
+		Based on new information from Igor Schein <igor@txc.com>
+		made additional compensation in Configure script
+		for 64 bit Solaris 7 and 8 gcc.
+
+		Added some 00FAQ info on the effect ordering of
+		the +fg and -FG options has on output format.
+
+		Improved NetBSD IPv6 configuration, based on a
+		suggestion from Thomas Klausner
+		<wiz@danbala.ifoer.tuwien.ac.at>.  Added code to
+		convert IPv4-mapped-in-IPv6 addresses to IPv4
+		addresses.
+
+		Updated the information in 00FAQ and the HP-UX 11
+		binary directory README files on the HP-UX 11 ipis_s
+		patch with new information supplied by Eric McWhorter
+		<emcwhorter@xsis.xerox.com>.
+
+		Added documentation on changes to HASFSTYPE and
+		HASNCACHE, and the new HASPRIVPRIPP.
+
+		Adjusted Configure for FreeBSD 5.0.  Made additional,
+		necessary changes to Configure and the BSDI sources
+		to eliminate load errors.
+
+		Added KAME IPv6 support to FreeBSD at the request
+		of Ollivier Robert <roberto@eurocontrol.fr>, who
+		provided a test system.
+
+		Corrected the script that generates the CHECKSUMS
+		files for binaries to correctly name the detached
+		PGP certificate.  The documentation bug was reported
+		by Michael Hennecke <hennecke@rz.uni-karlsruhe.de>.
+
+4.50		June 29, 2000
+		Added a NetBSD alpha test host, courtesy of Ray
+		Phillips <r.phillips@mailbox.uq.edu.au>.  An lsof
+		4.49 binary, built on Ray's 1.4.1 system was made
+		available prior to the 3.50 release.
+
+		Upgraded the system map file tests in /dev/kmem-based
+		Linux lsof, making the use of DEBIAN_LINUX_LSOF
+		unnecessary.  Tested the changes on a system made
+		available by Vincent Kujala <kujala@geog.ubc.ca>
+		and Jim Mintha <jim@ic.uva.nl>.
+
+		Forced AIX to use the large-file-enabled versions
+		of lstat (lstat64) and stat (stat64) if <sys/stat.h>
+		contains stat64.  This should allow lsof to stat()
+		AIX files > 2GB even when the builder has not
+		defined the "large file enabled programming
+		environment."  Configure tests <sys/stat.h> and
+		puts -DHASSTAT64 in the Makefile's CFLAGS to make
+		this happen.  Fernando A.B. Whitaker
+		<whitaker@cenapad.unicamp.br> reported the problem.
+		This was offered as a patch to 4.48.
+
+		Enabled Configure script to handle OpenBSD 2.7.
+		Angelos D. Keromytis <angelos@dsl.cis.upenn.edu>
+		reported the availability of OpenBSD 2.7 and supplied
+		the Configure script patch.
+
+		Improved handling of DOOR and fattach()'d files in
+		Solaris.
+
+		Changed message about missing kernel symbol file
+		from "not yet determined" to "none found".
+
+		Updated FreeBSD, NetBSD, NEXTSTEP, OpenBSD, and
+		OPENSTEP support to report "no PCB" and the values
+		of the SO_CANTSENDMORE and SO_CANTRCVMORE state
+		flags when a socket structure has no inpcb pointer.
+		This modification was made to AIX lsof at revision
+		4.46.  Added an entry to 00FAQ about sockets that
+		have no inpcb pointer.
+
+		Upgraded support for FreeBSD 5.0-CURRENT.  Ben
+		Smithurst <ben@scientia.demon.co.uk> supplied
+		patches and did testing.  David O'Brien <obrien@NUXI.com>
+		supplied a test system.  The update included dropping
+		the Fctty part of file descriptor file system
+		support, conditional on a Configure script test.
+		I propagated those changes to BSDI, NetBSD, and
+		OpenBSD in anticipation of their having the
+		modification in the future.  David also arranged
+		with Michael Haro <mharo@area51.fremont.ca.us> for
+		a FreeBSD 3.4 test system.
+
+		In response to an lsof 3.72 bug report from Jim Mewes
+		<jim@corp.phone.com>, added more kernel address
+		filtering to the lsof function, kread(), that reads
+		Solaris kernel data.
+
+		In response to a report from Marc Duponcheel
+		<marc@offline.be>, added tests to the /proc-based
+		Linux lsof to ignore file systems of types "autofs"
+		and "pipfs".
+
+		Based on a report and information supplied by Casper
+		Dik <casper@holland.Sun.COM>, updated the ncache_load()
+		function in lib/rnch.c with new code that deals
+		with a post Solaris 8 change in kernel name cache
+		(DNLC) handling.  Casper tested the update, which
+		should be invisible to Solaris versions without
+		the new DNLC code.
+
+		Added support for Solaris VxFS QIO files, based on
+		a report from Kieran Broadfoot <kieran.broadfoot@gs.com>.
+		Kieran help test the support.
+
+		Added support for PTX 4.4.6 and 4.5[.1] with help
+		from the usual cast of good people at Sequent.
+
+		Added support for 64 bit file sizes and offsets on
+		BSDI, FreeBSD, NetBSD, and OpenBSD, based on a
+		report from Dan Nelson <dnelson@emsphone.com>.
+		Dan supplied a patch and did FreeBSD testing.
+
+		Added Configure script recognition of NetBSD 1.5,
+		based on a report from Andrew Brown <atatat@atatdot.net>.
+		Thomas Klausner <wiz@danbala.ifoer.tuwien.ac.at> updated
+		the NetBSD port package to use a pre-release of this
+		addition.
+
+		At the last minute saw a notice via deja.com's
+		UseNet search service that FreeBSD 3.5 had been
+		released and lsof didn't grok it.  Added recognition
+		of 3.5 to lsof's Configure script, but didn't have
+		the opportunity to test lsof on 3.5.
+
+4.51		August 21, 2000
+		Added Configure script support for the upcoming
+		Solaris 9 release based on suggestions from Casper
+		Dik <Casper.Dik@holland.sun.com>.
+
+		Changed sample Perl scripts to assume that
+		/usr/local/bin/perl is Perl 5 and Perl 4 may be
+		found in /usr/local/bin/perl4.
+
+		Updated Configure to recognize FreeBSD 4.1 and made
+		a FreeBSD pre-release distribution available.
+
+		Bela Lubkin <belal@sco.COM> tested lsof on the
+		upcoming SCO OSR 5.0.6 release and reports that
+		lsof appears to work properly.
+
+		Updated the AIX compiler test in Configure to
+		recognize its version 5.
+
+		Updated AIX 4.3.3 support with automatic recognition
+		of the proper rnode structure, based on machine
+		bit width.  Also added code to detect when processing
+		the -X option that lsof has been compiled with the
+		"other" AIX 4.3.3 user structure and to apply
+		compensations.  When a compensation method works,
+		it's applied during subsequent -X processing; when
+		none works, further -X processing is disabled.
+
+		Added Tru64 UNIX 5.1 support.  Updated Tru64 UNIX
+		library text file support to recognize new kernel
+		support for AdvFS library files.  Berkley Shands
+		<berkley@cs.wustl.edu> and Klaus Saggerer USG
+		[saggerer@zk3.dec.com> helped put me in contact
+		with Chang Song <song@zk3.dec.com>, the developer
+		of 5.1's new kernel name cache and he helped me
+		develop new code in lsof to access it.
+
+		Corrected reporting of PTX fattach()'d address.
+
+		Changed Configure and dlsof.h for NetBSD and OpenBSD
+		to use /usr/include/uvm header files when available.
+		Andrew Brown <atatat@atatdot.net>, Thomas Klausner
+		<wiz@danbala.ifoer.tuwien.ac.at>, and Wolfgang
+		Rupprecht <wolfgang@wsrcc.com> pointed out the need
+		to do this for NetBSD.  Andrew provided access to
+		a NetBSD 1.5 system for verifying the changes.
+
+		Installed snprintf() support, including a private
+		version in the lsof library for those UNIX dialects
+		without the function.  Changed all sources to use
+		it instead of sprintf() and strcpy().
+
+		Fixed a memory leak in the readvfs() functions of
+		BSDI, DEC/OSF1, Digital UNIX, FreeBSD, NetBSD,
+		OpenBSD, and Tru64 UNIX.
+
+		Tested on Linux 2.4.
+
+		Modified the Pyramid MkKernOpts script to compensate
+		for `uname -s` configuration alternatives.  Robert
+		Dahlem <Robert.Dahlem@ffm2.siemens.de> supplied
+		the modification.
+
+		Obtained access to an FCS Solaris 8 64 bit system
+		and built lsof on it, using Sun Workshop C 5.0 and
+		gcc 2.96 20000814 (experimental).  Both compilers
+		produce a working lsof.
+
+
+4.52		November 8, 2000
+		Completed work on an HP-UX 11.11 port that uses a
+		pstat(2) interface provided by HP.  To distinguish
+		it from its predecessors for HP-UX, this lsof
+		version is called PSTAT-based and the predecessor
+		versions are now called /dev/kmem-based.  I am
+		indebted to the far-sightedness and support of
+		these good people at HP for making PSTAT-based lsof
+		possible: Carl Davidson, Louis Huemiller, Rich
+		Rauenzahn, and Sailu Yallapragada.  The PSTAT-based
+		sources are in lsof_4.52/dialects/hpux/pstat, the
+		/dev/kmem-based ones in lsof_4.52/dialects/hpux/kmem.
+
+		Ported to IBM Monterey for Merced|Itanium, aka AIX
+		5L.  It configures via the Configure script's "aix"
+		abbreviation and has been tested on AIX 5L Beta 3.
+		Jay Beck, Steve Dibbell, Loc Le, Nasser Momtaheni,
+		and Malcom Zung of IBM provided generous support.
+		Since AIX 5L is still in Beta testing, this port
+		can't be considered complete.
+
+		Added Configure support for OpenBSD 2.8.  David
+		Mazieres <dm@cs.nyu.edu> provided a test system.
+
+		Based on a report from Marc Christensen
+		<marc@mecworks.com> added sockfs to the mount scan
+		exemption list for /proc-based Linux lsof.
+
+		Added large file, CDFS, and DOSFS for UnixWare 7.x.
+		Added UnixWare device memory mapping support.  All
+		UnixWare changes were supplied by Eric Dumazet
+		<edumazet@cosmosbay.com>  Eric also supplied some
+		miscellaneous bug fixes.
+
+		Deferred name cache loading until printname() needs
+		to use the name cache.
+
+		Terminated Pyramid, SunOS 4.1.x, and Ultrix support,
+		because test systems are no longer available.
+		Final Pyramid and Ultrix source code distributions
+		for lsof revision 4.51 may be found on lsof.itap.purdue.edu
+		in pub/tools/unix/lsof/OLD/src.  The no longer
+		supported SunOS 4.1.x source code is still distributed
+		with the Solaris source code.
+
+		Added code to set Solaris node address to real vnode
+		address, when applicable.
+
+		John Speno <speno@lopan.isc-net.upenn.edu> provided
+		information that enabled me to update the Tru64
+		AdvFS (MSFS) node definition for AdvFS version 5.
+
+		Added Tru64 5.x CFS support with help from Kris
+		Chandrasekhar <Kris.Chandrasekhar@compaq.com>,
+		Diane Lebel <lebel@zk3.dec.com>, and John Speno.
+		The support only provides information about cached
+		file attributes.
+
+		Installed a Configure patch for HP-UX 11 supplied by
+		Kenneth Stailey <kstailey@disclosure.com> that adds
+		another command to q4 input.
+
+		Tested on FreeBSD 4.2.
+
+		Will Day <willday@rom.oit.gatech.edu> and Frank
+		Winkler <frank.winkler@germany.sun.com> graciously
+		supplied Solaris 8 binaries.
+
+		Added Solaris 9 text file support, supplied by
+		Casper Dik <Casper.Dik@holland.sun.com>.
+
+4.53		December 6, 2000
+		Added the AIX 5L j2_lock.h to the distribution with
+		a Configure script step to use it when it's missing
+		from /usr/include/j2.
+
+		Removed SunOS 4.1.x support.
+
+		Removed Linux 2.0.x /dev/kmem support.
+
+		Fixed VBLK and VCHR special device file reporting
+		to handle /dev information more accurately.
+
+		Added a Apple Darwin / Mac OS X 1.2 port, provided
+		by Allan Nathanson <ajn@apple.com>.  Allan also
+		arranged for a test system so I can maintain this
+		port.  An additional test system was provided by
+		Dale Talcott.
+
+		Dropped claims of support for all UnixWare versions
+		except 7.1.0, since that is the only version on
+		which I can test lsof.  Even though lsof 4.53 is
+		deprecated for UnixWare 2.1.3, installed a patch
+		for it with testing done by A. Channing Clark
+		<clark.channing@heb.com>.
+
+		Dropped claims of support for all SCO OpenServer
+		versions except 5.0.5, since that is the only
+		version on which I can test lsof.
+
+4.54		January 19, 2001
+		Added compensation for a change that made the
+		FreeBSD mount structure invisible.  I can only test
+		back to 3.2 and the compensation works there, so
+		it's been #ifdef'd for 3.2 and above.  David O'Brien
+		<obrien@FreeBSD.org> provided the necessary clue.
+
+		Based on a report from Valdis Kletnieks
+		<Valdis.Kletnieks@vt.edu>, changed all IPv6 support
+		to report a TYPE of IPv6 for sockets with IPv4
+		addresses mapped in IPv6 addresses.  The previous
+		lsof behavior was to report their TYPE as IPv4.
+
+		Restored the Linux GlibC test to Configure, removed
+		at revision 4.53, based on a report from John Dzubera
+		<zube@cs.colostate.edu>, that RedHat Linux 6.0 still
+		needs the test.
+
+		Made setting of link count for Solaris more selective.
+
+		Limited Readlink() recursion to MAXSYMLINKS.  The bug
+		was reported by Jan Dvorak <johnydog@go.cz>.
+
+		Dropped the *claim* that lsof runs on Solaris 2.5.1.
+		It may well do so, but I no longer have access to a
+		test system.
+
+		Fixed an #endif comment typo, reported by Igor Schein.
+
+		Fixed a typo in a cast for a Tru64 UNIX 5.1 function
+		and updated Configure for Tru64 UNIX 5.0 and 5.1 with
+		information from Jesse Perry <jesse.perry@compaq.com>.
+
+		Corrected non-fatal typos in the AdvFS support in
+		dnode.c for Tru64 UNIX.
+
+		Added msdos file system support for NetBSD and OpenBSD.
+		Andrew Brown <atatat@atatdot.net> requested and helped
+		test it.
+
+4.55		February 15, 2001
+		Based on a report from Bernd Eckenfels <ecki@lina.inka.de>
+		added support in lsof for files in /proc/<PID>/maps
+		that have been deleted.
+
+		Changed PGRP output title to PGID, conforming to
+		the most common current abbreviation for Process
+		Group ID (PGID).  While some systems continue to
+		use *pgrp for internal kernel variable names, most
+		systems that support the display of PGID via ps(1)
+		now title it PGID.  The lsof -g and -Fg options
+		operations are unchanged in function; only titles
+		and descriptions have changed.  Also changed internal
+		variable names from *PGRP and *pgrp to *PGID and
+		*pgid where possible.
+
+		Dropped the *claim* that lsof runs on HP-UX 9.x.
+		It may well do so, but I no longer have access to
+		a test system.
+
+		In response to a suggestion from Jeff Howie
+		<jeff.howie@federated.ca> added support for command
+		name selection by regular expression.  A new form
+		of the -c option value is use to identify and
+		specify a regular expression.
+
+		Restore the *claim* that lsof works on UnixWare
+		7.0, since I re-acquired a test system.
+
+4.56		May 3, 2001
+		Corrected some problems Amir Katz <Amir_Katz@bmc.com>
+		found with Insure++, one in lib/dvch.c, the rest
+		in Solaris sources.  Amir's report also helped me
+		find an error in an snpf() call that caused (the
+		unsupported) Solaris 2.5.1 lsof to crash.  Wally
+		Winzer, Jr. <wally.winzer@ChampUSA.COM> helped test.
+
+		Added support for UnixWare 7.1.1 and above in-kernel
+		UNIX sockets.  John Hughes <john@Calva.COM> kindly
+		provided code and access to a test system.  John
+		also provided a test system and advice for adding
+		UnixWare 7.1.1 NonStop Cluster and CFS support.
+		More help with that effort came from Kurt Gollhardt
+		(SCO), Barbara Howe (SCO), Bela Lubkin (SCO), and
+		Dewan Rashid <Dewan.Rashid@ir.com>.
+
+		Archived a set of compilation hints (patches) from
+		Bill Melvin <Bill.Melvin@esc.edu> that make it
+		possible to compile the old, unsupported lsof 3.08
+		sources on UnixWare 1.x without NFS or CDFS support.
+
+		Installed support supplied by Allan Nathanson
+		<ajn@apple.com> for the Darwin "Gold Master" release,
+		Mac OS X 10.0 (aka Darwin 1.3 in its public source
+		version).  Added Allan's CVS repository suggestions
+		to the script that gets additional header files
+		from an open source repository.
+
+		Tested an HP-UX 11.11 kernel patch from Sailu
+		Yallapragada that enables reporting of TCP/IP
+		information for telnetd processes that use the
+		telnet multiplexor.  I don't yet know the kernel
+		patch ID.
+
+		Made the Solaris inclusion of <inet/mi.h> conditional
+		on the Solaris version.  (It's apparently not needed
+		at 2.6 and above.)  Bill Watson <bill.watson@uk.sun.com>
+		brought this to my attention.
+
+		Added alternate Linux 2.4.x lock extent test, supplied
+		by Jim Mintha <jim@ic.uva.nl>.
+
+		Rearranged the lines and pre-processor tests in
+		regex.h, lib/regex.c, and lib/snpf.c so that unifdef
+		can be used to eliminate copyright and GPL statements
+		when the files aren't being used for a particular
+		dialect.  (USE_LIB_* definitions in a dialect's
+		machine.h header file determine if one or more of
+		those three files are to be used.)
+
+		Added preliminary support for Solaris 8 with VxFS
+		3.4.  This support will be refined as I get
+		information from Veritas about how they will
+		distribute the kernel header files lsof needs.
+		Those header files were omitted from the standard
+		VxFS 3.4 distribution.  Technical assistance and
+		testing were provided by Calle Dybedahl <cdy@algonet.se>,
+		Gary Millen <gary.millen@veritas.com>, Rainer Orth
+		<ro@TechFak.Uni-Bielefeld.DE>, Peter C. Vernam
+		<pvernam@draper.com>, and Donna Yobs
+		<Donna.Yobs@veritas.com>
+
+		Tested on FreeBSD 4.3-STABLE.
+
+		Dropped the *claim* that lsof works on UNIX dialects
+		where I no longer have test systems: BSDI 2.1,
+		3.[01] and 4.0; DEC OSF/1, Digital UNIX and True
+		64 UNIX 2.0 and 3.2; FreeBSD 2.1.[67], 2.2[.x],
+		3.[012345] and 4.[01]; HP-UX 10.20; NetBSD 1.[234];
+		SCO OpenServer 5.0.5; and SCO UnixWare 7.0
+
+		Tested on Solaris 9 BETA, s81_36.
+
+4.57		July 19, 2001
+		Help (-h) and version (-v) output now have URLs
+		for the newly created and timeliest lsof FAQ
+		(00FAQ in the lsof distribution) at:
+
+		  ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ
+
+		and the man page for the current lsof distribution
+		at:
+
+		  ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_man
+
+		Based on a report from Steve Laubscher
+		<slaubs@woodward.com>, modified dlsof.h for PTX
+		4.6[.1] to avoid a temporary dnlc_t definition
+		needed at PTX 4.5.1.
+
+		Corrected test for old Linux kernels in Configure.
+		Henri Karrenbeld <ishtar@cal044202.student.utwente.nl>
+		brought the error to my attention.  Limited Linux
+		claims to 2.1.72 and above in the documentation.
+
+		Improved HP-UX 11 Configure stanza and stream socket
+		handling.
+
+		Constructed a work-around for the HP-UX 11 optional
+		OnlineJFS package.  The work-around sadly requires
+		lsof to have a private version of the vx_inode
+		structure, since the OnlineJFS package doesn't
+		update <sys/fs/vx_inode.h>.  Troyan Krastev
+		<Troyan.Krastev@ricoh-usa.com> brought the bug to
+		my attention and Michael Bracewell
+		<michael@ra.TSS.PeachNet.EDU> provided a test system
+		where I developed the work-around.
+
+		Added locale support to lsof's isprint() test,
+		based on a suggestion from Dan Mercer <damercer@mmm.com>.
+		Lsof will use setlocale(), when that function and
+		its supporting <locale.h> header file are available.
+
+		Added OpenBSD 2.9 support.
+
+		Based on a report from Aaron Rhodes <arhodes@psionic.com>
+		and with testing help from Aaron, made the lsof
+		4.56 revision compile and work on OpenBSD 2.6.
+		While that OpenBSD version is no longer supported,
+		Aaron's report exposed a Configure script bug
+		affecting OpenBSD versions lsof does support.
+
+		Updated for FreeBSD 5.0-CURRENT.  Szilveszter Adam
+		<sziszi@petra.hos.u-szeged.hu> help test.  The lsof
+		FreeBSD ports packager, David O'Brien <obrien@FreeBSD.org>,
+		assisted.
+
+		Tested on AIX 5.1.  Loc Le and Nasser Momtaheni of
+		IBM provided test systems.
+
+4.58		September 13, 2001
+		Added options to safestrprt() and safestrprtn() to
+		surround the string with '"' and to suppress the
+		printing of an ending '\n'.  Use of these functions
+		in device cache file error message reporting answers
+		a suggestion for better error reporting from John
+		Jackson <jrj@purdue.edu>.
+
+		Fixed a Solaris 2.6 and above problem related to
+		searching for "large" (O_LARGEFILE) files by name;
+		lsof was using the wrong version of [l]stat(2).
+		The bug was reported by Daniel Trinkle
+		<trinkle@cs.purdue.edu>.
+
+		Added AIX 4.1.4 and above XTI socket support.
+
+		Added OSR Xenix Shared Data and Semaphore file type
+		support with modifications supplied by Bela Lubkin.
+
+		Updated OPENSTEP support with modifications from Carl
+		E. Lindberg <lindberg@clindberg.org>.  The changes
+		enable the correct reporting of executable and
+		library open files ("txt" type).
+
+		Limited claims of OpenServer support to the versions
+		where I currently test, 5.0.4 and 5.0.6.  (Lsof
+		probably works on 5.0.5.)
+
+		Enabled processing of -C option for PSTAT-based HP-UX
+		lsof.
+
+		Enabled and tested on FreeBSD 4.4.
+
+		Corrected a file system test example in 00QUICKSTART,
+		based on a report from Jun Biao WANG <wangjunb@cn.ibm.com>.
+
+		Made available for re-distribution a user-contributed
+		port of lsof 4.51 to Reliant UNIX 5.45.  Thomas
+		Mauterer <Thomas.Mauterer@philosys.de> contributed
+		the port.
+
+4.59		October 20, 2001
+		With the closing of the Sequent Synergy Links Lab
+		by IBM, terminated lsof support for PTX.  The last
+		tested PTX lsof revision, 4.58, is available on
+		lsof.itap.purdue.edu in .../lsof/OLD/src.
+
+		Adjusted for FreeBSD 5.0-CURRENT NFS header file
+		changes, based on a report from Jos Backus
+		<josb@cncdsl.com>.
+
+		Corrected a bug in the way Linux lsof identifies
+		the owner of a process.  Lionel Cons <lionel.cons@cern.ch>
+		reported the problem and tested the fix.  Added
+		code to avoid stat(2) calls on regular Linux files
+		whenever possible.  Lionel reported the need to do
+		this (AFS files) and tested the new code.
+
+		Added new output field for raw device number in
+		hex.  The field is identified with 'r'.  This field
+		is NOT selected when -F or -F0 is specified so that
+		its appearance won't disturb existing scripts that
+		process field output.
+
+		Added support for OpenUNIX 8.  A test system was
+		provided by Larry Rosenman <ler@lerctr.org>.
+		Matthew Thurmaier <matt@compclass.com> and many
+		people from Caldera provided technical assistance.
+
+		Added an additional UVM test to the NetBSD Configure
+		stanza.  Andrew Brown <atatat@atatdot.net> supplied
+		the test; it recognizes NetBSD 1.5Y UVM changes to
+		the vnode structure recently committed by Chuck
+		Silvers.
+
+		Applied Configure and get-xnu-headers.sh script
+		changes suppled by Allan Nathanson <ajn@apple.com>
+		for Darwin 1.4.
+
+		Added for Bela Lubkin <belal@mammoth.ca.caldera.com>
+		OSR-specific environment variables to supply values
+		to the Configure script.  The variables are described
+		in 00XCONFIG.
+
+		Added an IP version selector to the -i option
+		parameters.
+
+4.60		November 9, 2001
+		Added special handling to and corrected bugs in
+		the matching of IPv4 in IPv6 addresses to -i6:<...>
+		selectors.
+
+		Made 00FAQ corrections and updates, based on
+		discussions with Igor Schein <igor@txc.com>.
+
+		Modified Configure script to detect a 64 bit capable
+		gcc compiler and permit it to be used to build 64
+		bit (PA-RISC 2) lsof for HP-UX 11.00.  Tested with
+		HP's gcc package, which Rich Rauenzahn of HP kindly
+		installed on a test system at HP.  Stefan Marquardt
+		<stefan.marquardt@hagebau.de> helped test.
+
+		Made lsof's method of killing its child process
+		more robust, based on a suggestion from Bela Lubkin
+		<belal@caldera.com>.
+
+		Modified all dialect Makefile segments to accept
+		select -v #define's from the environment -- a
+		builder's comment, host, logname, system information
+		and user name.  This was done for Bela Lubkin, so
+		he can "tune" the -v output when he packages lsof
+		in the upcoming Caldera OSR 5.0.7 release.
+
+		Changed Perl scripts in scripts/ to put the lsof
+		path consistently in $LSOF.  Also added a fix from
+		Bela Lubkin to scripts/big_brother.perl5 that allows
+		it to tolerate SCO OSR "ago" clauses in open UDP
+		file information.  Strengthened emphasis in
+		scripts/00README that the scripts are examples that
+		shouldn't be expected to run on all UNIX dialects
+		without modification.
+
+		At Bela Lubkin's suggestion changed the device
+		cache file format examples in 00DCACHE and 00FAQ
+		to avoid "%U%".  That's an SCCS escape sequence.
+
+		Added support for OpenBSD 3.0.
+
+		Added +DAportable to CFLAGS for 32 bit HP-UX 11.
+		Amir Katz <Amir_Katz@bmc.com> suggested the addition.
+
+4.61		January 22, 2002
+		Updated field output example Perl scripts in the
+		scripts/ subdirectory to discover the lsof path,
+		starting at .. and proceeding through the PATH
+		environment variable's directories.
+
+		Added minor OSR Configure script fixes, provided
+		by Bela Lubkin <belal@caldera.com>.
+
+		In response to a report from Joshua Wright
+		<Joshua.Wright@jwu.edu> modified NetBSD and OpenBSD
+		Configure stanzas and sources so that lsof can be
+		built when there is no system source tree (e.g.,
+		/usr/src/sys).
+
+		In response to a report from Peter Valchev
+		<pvalchev@openbsd.org> improved the UVM test in
+		the OpenBSD Configure stanza.
+
+		Updated Configure script to recognize FreeBSD 4.5.
+		Updated for FreeBSD 5.0 procfs and pseudofs changes.
+
+		Updated HP-UX stanza to see if the compiler named
+		in the LSOF_CC environment variable is the bundled
+		compiler.  If it is, "-O" is omitted from the
+		compiler flags.
+
+		Updated Digital UNIX 4.x and Tru64 UNIX error message
+		related to kernel name list failures.  Added an FAQ
+		section about how a kloadsrv daemon failure can cause
+		knlist(3) to fail.  The condition was reported by
+		Douglas B. Jones <douglas@gpc.peachnet.edu>
+
+		Based on a report from Mark W. Eichin <eichin@thok.org>
+		made Linux lsof capable of handling and reporting
+		file sizes greater than 32 bits.
+
+		Tested on Solaris 9 BETA-Refresh.
+
+		Corrected a bug in the matching of IPv4 addresses,
+		mapped in IPv6 addresses, to an IPv4 parameter to
+		an -i option.
+
+		Ported to 64 bit Power AIX 5.1 kernel with advice
+		from David Clissold <cliss@austin.ibm.com> and Marc
+		Stephenson <marc@austin.ibm.com>, and on a test
+		system provided by Loc Le <lple@us.ibm.com>.
+
+4.62		March 7, 2002
+		Updated 00README to reflect the usefulness of gcc
+		for building AIX lsof.  Documented a report from
+		Brian L. Gentry <BGentry@nationsrent.com> of success
+		on AIX 4.3.3.  I documented my success on 32 bit
+		Power AIX 5.1 and my lack of success on ia64 AIX
+		5.1 and 64 bit Power AIX 5.1.
+
+		Improved UnixWare >=7.1.1 reporting of UNIX socket
+		NAME field information for NonStop Cluster systems
+		with a patch provided by John Hughes <john@Calva.COM>.
+		Offered John's improvement as a patch to lsof 4.61.
+
+		Corrected bugs in handling of open files on block
+		devices by OSR lsof.  The bugs were reported by
+		Bela Lubkin <filbo@deepthought.armory.com>.
+
+		Fixed bug in writing >32 bit device numbers for
+		block devices to the device cache file.
+
+		Added support for reporting block special nodes
+		not in /dev (or /devices).  That required "like
+		device special" be changed to "like block special"
+		and "like character special".  (00FAQ was updated.)
+
+		Based on a report from Peter Valchev <pvalchev@openbsd.org>
+		improved the definition of the source for NetBSD
+		and OpenBSD kernel symbols (the nlist() source
+		file).  NetBSD now defaults to getbootfile(3) if
+		it is available, /netbsd otherwise.  OpenBSD now
+		defaults to /dev/ksyms if it is available, /bsd
+		otherwise.
+
+		Made possible compilation under BSD/OS (BSDI) 5.0
+		with changes to Configure, dialects/bsdi/dlsof,
+		dialects/bsdi/dproc.c and lib/rnmh.c.  The changes
+		were suggested by Steven Hinkle <hinkle@bsdi.com>.
+		Note that these changes do not substantiate a claim
+		that lsof works on BSDI 5.0, because I haven't
+		tested it there.
+
+		Updated OpenUNIX private <sys/fs/memfs_mnode.h>,
+		based on a report from Larry Rosenman <ler@lerctr.org>
+		that it had been updated by Caldera patch OU800PK3.
+		Unfortunately the patch only corrects some of the
+		problems with the header file, so it is still
+		necessary to distribute a private patched version
+		of it with the lsof sources.
+
+		Applied a man page correction reported by Frederic
+		Delanoy <max_ok@yahoo.com>.
+
+		Corrected cast bugs related to using the HP-UX
+		bundled C compiler on HP-UX 11.11.
+
+4.63		April 23, 2002
+		Added HPUX_BOOTFILE environment variable for use
+		by the Configure script in determining HP-UX kernel
+		configuration information -- e.g., the state of
+		the ipis_s structure in the HP-UX 11 kernel.  The
+		change was suggested by Marc Bejarano <beej@alum.mit.edu>.
+		Marc also suggested some changes to the HP-UX
+		section in 00FAQ that discusses Configure's use of
+		q4 for HP-UX 11.
+
+		Fixed a bug in the Solaris lsof file system matching
+		code.  It was not reporting that VCHR files in
+		/devices were in / when /devices was in /, too.
+
+		Corrected bugs in device number, file size, file
+		offset, and raw device number field output generation.
+
+		Added recognition of OpenBSD 3.1 to the Configure
+		script with a suggestion from Peter Valchev
+		<pvalchev@sightly.net>.  Note that this change does
+		not constitute a claim that lsof works on OpenBSD
+		3.1, because I haven't tested it there.
+
+		Built an automated test suite.  (See 00TEST and
+		the tests/ sub-directory of the lsof main directory).
+		Bela Lubkin requested it.  Dale Talcott, John
+		Hughes, and Larry Rosenman helped me validate it
+		on their systems.
+
+		During the development of the test suite I discovered
+		the following lsof bugs or missing features, and
+		corrected or supplied them.
+
+		* Corrected the reporting of locks for:
+		  o Digital UNIX 4.0d and Tru64 Unix 5.[01];
+		  o HP-UX 10.30 and 11.00;
+		  o OpenUNIX 8;
+		  o UnixWare 7.1.1.
+
+		* Enabled HP-UX 10.30 and 11.00 to report open NFS
+		  file link counts.
+
+		* Corrected the reporting of UNIX domain socket
+		  names for Apple Darwin, FreeBSD 4.5 and above,
+		  NetBSD 1.4.1 and above, and for OpenBSD 3.0 and
+		  above.
+
+		* Enabled HP-UX 11.11 to stat(2) large files.
+
+		* Fixed handling of combination 32 and 64 bit
+		  device numbers in AIX 64 bit architectures.
+
+		Updated the AIX 4.3.3 NFS rnode recognition code,
+		first installed at revision 4.51.  It looks like
+		some IBM update has restored a single rnode structure
+		independent of the machine bit width.
+
+		Updated the NetBSD and OpenBSD sources so NetBSD
+		can process DTYPE_PIPE files, as OpenBSD was already
+		able to do.
+
+		Updated Darwin get-xnu-headers.sh script to reflect
+		information about a recent reorganization of the
+		Darwin CVS hierarchy, supplied by Allan Nathanson
+		<ajn@apple.com>.
+
+		Added defense against the standard I/O descriptor
+		attack.
+
+4.64		June 26, 2002
+		Corrected some FreeBSD pre-processor directives.
+		David O'Brien <obrien@NUXI.com> pointed them out.
+
+		Updated lsof's main() function to: 1) close all
+		open file descriptors above 2 before starting; and
+		2) to set a non-interfering umask.  Moved GET_MAX_FD
+		test from misc.c to proto.h, so that main() could
+		use it.  Added multiple-include protection to
+		proto.h.
+
+		Moved FAQ's test suite Q's & A's to a more appropriate
+		section.  Added a Q&A on HASSECURITY option and
+		its affect on searching for open files.  (That was
+		already in the man page.)
+
+		Updated hpux/kmem/dnode.c for HP-UX < 11 compilation
+		with information from John Dzubera <Zube@CS.ColoState.EDU>.
+		While lsof doesn't support HP-UX < 11 any more, I
+		try to avoid disabling it there when possible, and
+		a locking fix for HP-UX >= 11 in lsof 4.63
+		inadvertently disabled compilation of lsof for
+		HP-UX < 11.  Fixed long-standing bug in HP-UX 10.20
+		lock reporting.
+
+		Removed language from the test suite programs that
+		requires an ANSI-C compiler.  This allowed the test
+		suite to be validated with cc and gcc on the un-
+		supported HP-UX 10.20.
+
+		At the suggestion of Manuel Bouyer <bouyer@antioche.eu.org>
+		switched NetBSD and OpenBSD lsof from using nlist()
+		to using kvm_nlist().  Made the same change for
+		BSDI, Darwin, and FreeBSD.
+
+		Validated test suite on OPENSTEP 4.2.
+
+		In response to a suggestion from Jeff Stoner
+		<jstoner@blackboard.com> enhanced support for the
+		FD list of the -d option to allow it to be either
+		an exclusion or inclusion list, using the '^' prefix
+		to denote exclusions.
+
+		Made adjustments for FreeBSD 4.6 and 5.0-CURRENT.
+		Fixed a FreeBSD /etc/make.conf CFLAGS extraction
+		bug, reported by Kris Kennaway <kris@obsecurity.org>,
+		and new a bug in the fix, reported by Eric Cronin
+		<ecronin@eecs.umich.edu>
+
+		Added nullfs support for FreeBSD, NetBSD, and OpenBSD
+		at the request of Andrew Brown <atatat@atatdot.net>.
+
+		Modified all readmnt() functions to ignore mounted-on
+		directory names that don't begin with '/'.
+
+		Tested on NetBSD 1.6A and OpenBSD 3.1.
+
+		Upgraded to Solaris 9 FCS with two changes to the
+		BETA-Refresh support: 1) an adjustment to dnode.c
+		for a change in the so_so (sonode) structure; and
+		2) addition of Solaris 9 FCS specific DNLC code.
+		David Comay <David.Comay@Eng.Sun.COM> sent me the
+		dnode.c change and Casper Dik <Casper.Dik@sun.com>
+		helped with the new DNLC support code.
+
+		Applied OpenUNIX changes that permit lsof to compile
+		and run on the upcoming 8.0.1 release.  The changes
+		were supplied by Robert Lipe <robertl@caldera.com>.
+		Larry Rosenman <ler@lerctr.org> provided a test
+		system.
+
+		Added Solaris fd file system support.
+
+4.65		October 10, 2002
+		Adjusted for change in FreeBSD 5.0-CURRENT inode
+		structure, reported by David O'Brien <obrien@NUXI.com>.
+		Adjusted for changes in FreeBSD 5.0-CURRENT <sys/vnode.h>.
+		One change was reported by Anders Nordby
+		<anders@FreeBSD.org>.  Adjusted for FreeBSD 5.0-CURRENT
+		on sparc64 architecture.
+
+		Enhanced the error reporting of Solaris lsof when
+		it detects a kvm_open() failure, and added a 00FAQ
+		entry on the cause, based on a report from Peter
+		J. Bertoncini <pjb@anl.gov>.
+
+		Enabled compiling of lsof for NetBSD 1.5 with the
+		NULL file system, using a patch from Andrew Brown
+		<atatat@atatdot.net>.
+
+		Removed a hack in the LTbigf test program that was
+		once needed when it was compiled on Solaris 9 BETA-
+		Refresh with gcc.  The hack isn't needed on Solaris
+		9 FCS.  Janet Hempstead <jan@library.carleton.ca>
+		brought the need for this change to my attention.
+
+		Applied a patch, supplied by Andrew Brown
+		<atatat@atatdot.net>, that updates lsof for NetBSD
+		version 1.6F.  Corrected handling of the NetBSD
+		nullfs.
+
+		Updated to BSDI BSD/OS 4.3 on a test system kindly
+		provided by Terry Kennedy <terry@tmk.com>.
+
+		Updated to FreeBSD 4.7.
+
+		Updated to Apple Darwin 1.5, 5.x and 6.x with
+		patches supplied by Allan Nathanson <ajn@apple.com>.
+		The patches include IPv6 support.
+
+		Updated Configure to use the -bnolibpath loader
+		option when building lsof on a PowerPC, running
+		AIX 5 or greater.  Valdis Kletnieks
+		<Valdis.Kletnieks@vt.edu> informed me this was
+		needed.  Lsof for AIX 5.x was initially developed
+		on the IA64, where -bnolibpath can't be used and
+		I didn't think to restore it to PowerPC loads when
+		AIX 5.x became available for that architecture.
+
+		Updated to UnixWare 7.1.3 on a test system provided
+		by Larry Rosenman <ler@lerctr.org>.  Removed claims
+		that lsof works on OpenUNIX 8.0.1, because UnixWare
+		7.1.3 is the release name of OpenUNIX 8.0.1.
+
+		Based on a comment that his e-mail address was
+		wrong in the lsof distribution from Kenneth Stailey
+		<kstailey@disclosure.com>, removed all e-mail
+		addresses from lsof documentation files except this
+		one, 00DIST.  The addresses in 00DIST are used to
+		send revision release notices to those who contributed
+		to a revision, but the addresses in this file for
+		previous revisions and in other documentation files
+		sometimes grow stale and are never validated.
+
+4.66		December 22, 2002
+		Acquired Solaris 7 and 8 test systems, courtesy of
+		John Dzubera <Zube@CS.ColoState.EDU>.  Updated
+		00TEST and tests/TestDB accordingly.
+
+		Clarified FreeBSD 5.0 architecture claims at the
+		suggestion of David O'Brien <obrien@NUXI.com>.
+		Also implemented David's suggestion to change
+		Intel to x86.
+
+		Installed changes to DNLC handling in OSR lsof in
+		preparation for handling changes in the OSR 5.0.7
+		DNLC cache.  Information about the changes and
+		patches to handle them were supplied by Bela Lubkin
+		<filbo@deepthought.armory.com>.
+
+		Upgraded True 64 UNIX support to the 5.1B release
+		on a test system provided by Berkley Shands
+		<berkley@cse.wustl.edu>  Had to used relaxed ANSI
+		compilation because of an error in a system header
+		file and other lsof source usages.
+
+		Implemented the HASNOSOCKSECURITY compile-time
+		option.  When it and HASSECURITY are defined, lsof
+		will be built to list only the user's open files,
+		but will also list anyone else's open socket files,
+		provided the "-i" option selects their listing.
+		Updated the Customize script to ask about setting
+		HASNOSOCKSECURITY.  Left it undefined in all dialect
+		machine.h header files.  This change was requested
+		by Kenneth Stailey <kstailey@speakeasy.net> for
+		use with ntop.
+
+		Added support for OpenBSD 3.2 and its kernel trace
+		file.
+
+		Improved lsof help (-h) and version (-v) information
+		reporting.
+
+		Fixed a FreeBSD 4.7 and above off-by-two UNIX domain
+		socket path termination bug, reported by Ken Stailey
+		<kstailey@speakeasy.net>
+
+4.67		March 27, 2003
+		Began the transition of the lsof ftp server host
+		name from vic.cc.purdue.edu to lsof.itap.purdue.edu.
+		That reflects Purdue organizational changes.  This
+		first step makes the new name an alias to the old
+		one.   The old name, vic.cc.purdue.edu, will remain
+		usable for an extended period.
+
+		Corrected a revision number reference in section
+		17.17 of 00FAQ on the appearance of Solaris negative
+		DNLC caching handing.
+
+		Updated 00FAQ discussion of compilers for 64 bit
+		Solaris.
+
+		Validated test suite for 64 bit Solaris 8 and gcc.
+
+		At the request of Alek O. Komarnitsky <alek@komar.org>
+		added the "+c <width>" option to enable optional
+		changing of the COMMAND column output maximum width
+		from the default to <width>.  The default maximum
+		width remains CMDL, as defined in lsof.h.
+
+		Fixed three AIX kernel bit size detection bugs,
+		one in the AIX Configure script stanza, the second
+		and third in the AIX dproc.c get_kernel_access()
+		function.  The bugs were reported by Pierre-Yves
+		Fontaniere <pyf@cc.in2p3.fr>, who tested the fixes.
+
+		Added kernel event queue file support for FreeBSD,
+		NetBSD and OpenBSD.  Andrew Brown <atatat@atatdot.net>
+		supplied the code.
+
+		Updated to AIX 5.2 on a test system provided by
+		Dale Talcott <dtalcott@purdue.edu>.  Had to build
+		work-arounds for two missing AIX 5.2 header files,
+		<j2/j2_snapshot> and <proc/proc_public.h>.  Corrected
+		an off-by-one UNIX socket addressing bug.  Taught
+		AIX lsof to handle both jfs and jfs2 files at the
+		same time.  Adjusted for an IBM mistake in the
+		sizing of the fdsinfo structure in <procinfo.h>
+		Toshiya Nakamura <TOSHIYAN@jp.ibm.com> helped test,
+
+		Updated to FreeBSD 4.8.  Corrected another bug in
+		FreeBSD UNIX domain socket name handling.
+
+		Corrected gcc build problems on HP-UX 11i, reported
+		by Yuliy Minchev <yuliy@mobiltel.bg>.
+
+		Updated BSDI BSD/OS support to 4.3.1.
+
+		Augmented a lock ID test on NetBSD to check if the
+		ID is an LWP pointer.
+
+4.68		June 18, 2003
+		Enhanced Configure script's cleanup operations.
+
+		Added support for OpenBSD 3.3, based on a report
+		from Peter Valchev <pvalchev@sightly.net>.
+
+		Improved the description of the detached PGP
+		signature certificate file in the main lsof README
+		file, based on a suggestion from Diana Stockdale
+		<diana@mpl.ucsd.edu>.
+
+		Installed a work-around for FreeBSD 5.0-CURRENT on
+		Alpha to avoid a compiler register use complaint.
+
+		Corrected a 'c' option error message.  Gnele
+		<blaadeleng@yahoo.com> reported the problem.
+
+		Upgraded EXT2FS and UFS support for NetBSD and
+		OpenBSD to handle new inode information, and the
+		fast UFS1 and UFS2 file systems.
+		
+		With the help of Andrew Brown <atatat@atatdot.net>
+		determined the NetBSD snapshot (1.6F) at which
+		<sys/mount.h> could be included under _KERNEL, thus
+		eliminating the lsof netexport.h hack.  The same
+		change applies to OpenBSD versions 3.3 and above.
+
+		Applied a patch from Armin Gruner <ag@muc.de> that
+		corrects the use of the HASPROCFS definition in the
+		FreeBSD dialect sources.
+
+		Corrected spelling errors in 00FAQ and in the
+		generated 00.README.FIRST_<version> file of the
+		distribution archive.  John Jackson <jrj@purdue.edu>
+		and Ray Phillips <r.phillips@jkmrc.uq.edu.au>
+		spotted and reported the errors.
+
+		Corrected a spelling error in a comment and incorrect
+		use of an alarm function in the LTsock test program.
+
+		At the suggestion of Stuart Anderson <sba@srl.caltech.edu>
+		added preliminary (and incomplete) SAM-FS file system
+		support to Solaris lsof.  Completion awaits availability
+		of SAM-FS internals.
+
+		Fixed a Solaris device name printing bug, reported by
+		Ric Anderson <ric@tick.Telcom.Arizona.EDU>, only
+		visible when HASDCACHE is not defined.  Ric helped
+		test the fix.
+
+		Fixed an AIX kernel bit size handling bug related
+		to the NFS node (rnode) structure.
+
+		Corrected a print_kptr() function call error in the AIX
+		AFS code, reported by David Steiner
+		<david.r.steiner@Dartmouth.EDU>.  Upon further reflection
+		and because I no longer have appropriate AIX AFS test
+		systems, disabled AIX AFS support in the Configure script
+		for AIX versions above 4.3.3.0 or AIX AFS versions above 3.5.
+
+		Added support for FreeBSD 5.1.
+
+		With advice from Allan Nathanson <ajn@apple.com> adjusted
+		the Darwin get-xnu-headers.sh script to access the kernel
+		header files needed by lsof from a new form of the Apple
+		open source repository.
+
+		Installed Linux and lsof library bug fixes and
+		improvements, supplied by Marian Jancar <mjancar@suse.cz>.
+		One Linux improvement handles mount strings that
+		have octal escapes in them, eg., \040 for embedded
+		blanks.  Marian tested the changes.
+
+4.69		October 16, 2003
+		Received and applied an OpenBSD patch from Peter Valchev
+		<pvalchev@sightly.net> that replaces a ctob() call with
+		a sysconf() call.  Peter claims sysconf() is needed for
+		OpenBSD on SPARC.  (It is not needed for NetBSD on SPARC.)
+
+		With the upgrade of my only Solaris 7 test system
+		to, Solaris 8, dropped the *claim* that lsof works
+		on Solaris 7.  That doesn't mean it won't work
+		there, so those who want lsof for Solaris 7 probably
+		should be able to build it there and it probably
+		will work there.
+
+		Revised lsof's DNLC handling for BSD derivatives,
+		including: BSDI; Darwin, DEC OSF/1, Digital UNIX
+		and Tru64 UNIX; FreeBSD; NetBSD; and OpenBSD.  The
+		latest NetBSD distribution's dropping of the vnode
+		capability ID (v_id) required the revision.
+
+		Adjusted to the latest FreeBSD 5.1-CURRENT.
+
+		Added NetBSD support for using kvm_getproc2().
+
+		Added a patch from Andrew Brown <atatat@atatdot.net>
+		to handle NetBSD enum conflicts and changes in the
+		<miscfs/kernfs/kernfs.h> and <miscfs/procfs/procfs.h>
+		header files.
+
+		Added a "#define _KERNEL" to the AIX dnode2.c source
+		file for compatibility with a new <j2/j2_inode.h>
+		AIX 5.2 header file version.  The addition was
+		supplied by Dick Dunbar <Dick.Dunbar@Siebel.com>
+		and was offered as a patch to lsof 4.68/
+
+		Added support for a second type of Solaris SAMFS.
+		Stuart Anderson <sba@srl.caltech.edu> provided the
+		support.  SAMFS support in lsof SOLARIS remains
+		scanty, because Sun won't release any details on
+		its kernel structures.
+
+		Dropped the *claim* that lsof works on AIX 4.3.3,
+		because I was unable to test it there.  That doesn't
+		mean it won't work there, so those who want lsof
+		for AIX 4.3.3 probably should be able to build it
+		there and it probably will work there.
+
+		Updated for Solaris 10 on test systems provided by
+		Mike Miscevic <miscevic@hotpop.com>.  Casper Dik
+		<casper@holland.sun.com> provided significant help.
+		During the Solaris 10 port found and fixed an lofs
+		handling bug that prevented reporting of open lofs
+		file lock status.
+
+		Updated the DNLC test, LTdnlc, to provide a possible
+		explanation about file systems on which the test
+		might fail.
+
+		Modified the procedure for obtaining missing Darwin
+		XNU kernel header files.  The new one requires more
+		manual intervention, but is the best that can be
+		done with the way Apple open sources are now
+		organized.  00FAQ explains the new procedures for
+		those not used to downloading Apple open source
+		files.
+
+		Added support for Apple Darwin 7.0 (Mac OS X 10.3)
+		with patches supplied by Allan Nathanson <ajn@apple.com>.
+		Dropped the *claim* that lsof builds and works on
+		Apple Darwin below 6.0.
+
+		Validated lsof on FreeBSD 4.9, using a test system
+		provided by Ben Lewis <bl@purdue.edu>.
+
+		Validated lsof on FreeBSD 5.1-CURRENT for Amd64.
+		David O'Brien <obrien@FreeBSD.org> provided a test
+		system.
+
+		Changed the NetBSD Configure stanza to do header
+		file searches in /usr/include by default.  The
+		LSOF_INCLUDE and NETBSD_SYS environment variables
+		may still be used to specify other search paths.
+		Discussions with Andrew Brown and Wolfgang S.
+		Rupprecht <wolfgang@wsrcc.com> led to the change.
+
+4.70		January 16, 2004
+		Improved shell-portability of the linux stanza of
+		the Configure script with a patch from Paul Jarc
+		<prj@po.cwru.edu>.
+
+		Added a "silent" rule to tests/Makefile for Paul.
+		Updated, extended and clarified the test suite
+		documentation in 00FAQ and 00TEST.
+
+		Fixed Solaris 10 dlsof.h typo, reported by Mike
+		Miscevic <miscevic@hotpop.com>.  The typo prevents lsof
+		from loading cleanly in Solaris 10 builds past 40.
+
+		Fixed a Solaris HSFS node number reporting bug and
+		added a structure definition work-around for Solaris
+		10.
+
+		Converted PGP signing to GPG.  My previous PGP key can
+		be used, but the gpg "--allow-non-selfsigned-uid"
+		option may have to be used when it is imported into a
+		GPG key ring.
+
+		Added bz2 compression.
+
+		Updated for OpenBSD 3.4.
+
+		Added a work-around for a missing header file in the
+		s10_44 Solaris 10 build.
+
+		Added support for FreeBSD 5.2-BETA and 5.2-CURRENT.
+
+		Updated Linux AX25 support with modifications supplied
+		by Lutz Poetschulat <dl9cu@db0zwi.de>.
+
+		Added raw IPv6 support to Linux lsof.
+
+		Improved handling of parameters after "-i@".
+
+		Improved file name test in LTdnlc.c.
+
+		Added loop count controls to the reading of Solaris
+		lock chains.  The change was implemented as a result of
+		a report from Steve Gonczi <steve@relicore.com>.
+
+		Based on a report from John Jackson <jrj@purdue.edu>,
+		enabled a Solaris 10 <sys/lgrp.h> work-around for
+		Solaris 9, too.  (Patch 112233 installs an lgrp.h on
+		Solaris 9 that needs the work-around.)
+
+		With help from Andrew Brown <atatat@atatdot.net> and
+		John Heasley <heas@netbsd.org> added log-structured
+		file system (LFS) support for NetBSD and OpenBSD.
+
+		Added AMD64 to the list of FreeBSD 5.x-CURRENT
+		supported architectures.  FreeBSD.org provides a test
+		system, courtesy of (I believe) David O'Brien
+		<obrien@FreeBSD.org>.
+
+		Added a cast to lseek() in the HP-UX /dev/kmem-based
+		kread() function to make it work properly with the
+		bundled HP C compiler.
+
+4.71		March 11, 2004
+		Added text file support to Apple Darwin lsof and
+		enabled the lsof executable portion of the LTbasic
+		test.  Added support for Darwin kernel queue, POSIX
+		semaphore and POSIX shared memory files.  Tested on
+		Darwin 7.2 (aka Mac OS 10.3.2).
+
+		Added process_kqueue() function prototypes for FreeBSD,
+		NetBSD and OpenBSD.
+
+		Picked some lint in AIX sources, lib/rnmh.c and
+		tests/LTsock.c.
+
+		Added "-x [fl]" cross-over option, which enables +d and
+		+D processing to cross over symbolic links and|or file
+		system mount points.  Discussion with Johan Lindquist
+		<johan@smilfinken.net> and Eric Williams (aka The Ghost
+		In The Machine) <ewill3@earthlink.net> on Linux news
+		groups revealed the need for the option.
+
+		Updated support for UnixWare 7.1.4.
+
+		Added support for the optional reporting of socket
+		options, socket states and TCP flags for most currently
+		supported dialects. John Smith <lbalbalba@hotmail.com>
+		and Tristan Nefzger <tn@bhtrader.com> requested the
+		information.  The dialects and their versions for which
+		this feature has become available include:
+
+		    AIX 4.3.2 and 5.[12]
+		    Apple Darwin 7.2
+		    BSDI BSD/OS 4.3.1
+		    Digital UNIX and Tru64 UNIX 4.0
+		    FreeBSD 4.9 and 5.2
+		    HP-UX 11 and 11.11 (aka 11i)
+		    NetBSD 1.6ZH
+		    OpenBSD 3.4
+		    OPENSTEP 4.2
+		    OpenUNIX 8
+		    SCO OpenServer Release 5.0.6
+		    Solaris 2.6, 8, 9 and 10
+		    UnixWare 7.1.[134]
+
+		Modified the Configure stanza for HP-UX 11 with better
+		q4 detection.  Steve Bonds <3vhmxxm02@sneakemail.com>
+		supplied the modification.
+
+		Applied a patch from Mike Miscevic <miscevic@hotpop.com>
+		to enable lsof to compile with the zone support in the
+		Solaris 10 s10_b51 release.  Added information on lsof
+		zone behavior to 00FAQ.
+
+		Added a "-z [z]" option to Solaris 10 lsof.  It enables
+		the listing of zone name and can also be used to select
+		the listing of processes and their files from specified
+		zones.
+
+4.72		July 13, 2004
+		Corrected Solaris 10 ZONE column title display bug with
+		a patch from Joep Vesseur <Joep.Vesseur@Sun.COM>.  Joep's
+		fix was offered as a patch to 4.71.
+
+		Based on a report from Jean-Pierre Radley <jpr@jpr.com>
+		about an unexpected GNU uname Configure interaction on
+		OSR, and working from information received from Bela
+		Lubkin, changed the OSR Configure stanza to use
+		/bin/uname instead of uname.  Added an FAQ entry about
+		Configure version detection problems.
+
+		Added the +m and "+m m" options in response to a dialog
+		with Robert T. Brown <rbrown@netmentor.com>.  The
+		options allow the creation of a mount table supplement
+		file which can be used on selected dialects to get
+		device numbers when stat(2) and lstat(2) can't deliver
+		them.  (That's generally the result of an inaccessible
+		NFS server.)  Currently the new options are supported
+		only on Linux.
+
+		Made cpumask_t typedef _KERNEL compensation for FreeBSD
+		5.2-CURRENT.  Refined it for 5.2.1-RELEASE with testing
+		help from Scott Ellentuch <tuc@ttsg.com>.
+
+		Added support for FreeBSD 4.10.  Larry Rosenmann
+		<ler@lerctr.org> kindly provided a test system.
+
+		Added support for NetBSD 2.0 with patches supplied by
+		Andrew Brown <atatat@atatdot.net>.  Andrew also
+		provided two test systems.
+
+		Made handling of Linux maps file more robust, based on
+		a report from Jan Blunck <J.Blunck@tu-harburg.de>.  As
+		a side benefit, made handling of generated stat(2)
+		information more flexible.
+
+		As a result of a discussion with Jason Fortezzo
+		<fortezza@mechanicalism.net>, adjusted lsof for Solaris
+		to obtain the maximum user name length from ut_name of
+		the utmpx structure, if <utmpx.h> exists.
+
+		Tested under OpenBSD 3.5.
+
+		Updated 00README information about using gcc (via the
+		Configure aixgcc abbrevisiation) to compile lsof on
+		AIX.  Ann Janssen <ajanssen@nebook.com> made me aware
+		the information was out of date.
+
+		Added an AIX SIGDANGER handler and some 00FAQ sections
+		on lsof memory usage after a discussion with Tom Qin
+		<tom.qin@citigroup.com> about lsof memory usage.
+
+		Added scripts/sort_res.perl5, contributed by Fabian
+		Frederick <fabian.frederick@gmx.fr>.  The script
+		displays lsof output sorted by size and path name.
+
+		Improved handling of files on Linux NFS mount points
+		that use the root_squash option, based on discussions
+		with Paul Szabo <psz@maths.usyd.edu.au>.
+
+		Updated FreeBSD 5.2-CURRENT support, based on a problem
+		report from Filippo Natali <filippo@widestore.net>.
+
+		Corrected improper FreeeBSD 5.x-CURRENT #if condition,
+		reported by Kim Culhan <kimc@kim.net>.
+
+		Added a Configure script work-around for AIX 5.2 lsof
+		with JFS2, compiled by gcc >= 3.3.  The work-around
+		was supplied by Florian M. Weps <fmw@hactrn.ch>.
+
+4.73		October 21, 2004
+		Added an __XPG4_CHAR_CLASS__ #define before
+		#include'ing <ctype.h> on Solaris to restore lsof's
+		ability to display special characters such as acute-e.
+
+		Added wide-character (e.g., UTF-8) support where
+		possible, prompted by a request from Kyungjoon Lee
+		<kjoonlee@gmail.com>.  Some older dialects -- e.g.,
+		NetBSD 1.4.1 -- don't support wide characters, so the
+		wide character support is enabled by definitions in
+		each dialect's machine.h.  Dialects with wide-
+		character support are listed in 00FAQ.
+
+		Make a FreeBSD 5.2-CURRENT adjustment for <sys/pipe.h>,
+		supplied by Sergey A. Osokin <osa@FreeBSD.ORG>.
+
+		Implemented a Linux feature request made by Jakub
+		Jelinek <jakub@redhat.com> that enhances lsof's ability
+		to locate UNIX domain sockets whose paths are named as
+		arguments.  Jakub supplied suggested code.
+
+		Dropped *claims* that lsof works on AIX below 5.1, SCO
+		Dropped *claims* that lsof works on AIX below 5.1, SCO
+		Openserver 5.0.4, Tru64 UNIX 5.0, and UnixWare below
+		7.1.4.  Lsof will probably build and work on those UNIX
+		dialect versions, but I no longer have any way to test
+		lsof on them.
+
+		Added support for FreeBSD 5.3 and 6.0.  The FreeBSD
+		5.3 support hasn't been tested.
+
+		Added FD test code that will allow dialect versions to
+		test FD option selections.  Used the new code in the
+		PSTAT-based HP-UX lsof to enable it to avoid scanning
+		the mount table when its information is not needed.
+		The addition was made in response to a query from
+		Harvey Garner <Harvey.Garner@championusa.com> about
+		lsof performance in a busy NFS environment.
+
+		Upgraded lsof's AIX support level to AIX 5.3, based on
+		a report from Dick Dunbar <Dick.Dunbar@Siebel.com>.  (I
+		have not tested lsof under AIX 5.3.)  Based on Dick's
+		recommendation and local testing changed the C for AIX
+		version 6 and higher -qmaxmem option value to -1.
+
+		Made LSOF_AR environment variable more useful and
+		documented it in 00XCONFIG.
+
+		Corrected the use of sum(1) to generate signatures for
+		the lsof distribution and binaries to match the
+		documentation that claims it is sum -r output.  Jin
+		Guojun <jin@george.lbl.gov> noticed and reported the
+		problem.
+
+		Tested under OpenBSD 3.6.
+
+		Added checksum and GPG certificate files for the bz2,
+		gz and Z lsof distribution archives.  The new files
+		reside with the distribution archives and supplement
+		the signature information already inside the archives.
+
+		Validated on Solaris 10, i8xpc, build s10_63.
+
+4.74		January 17, 2005
+		Fixed a Solaris segment fault bug on systems that lack
+		a /dev/allkmem device.  Offered the fix as a patch to
+		lsof 4.73.  The bug was reported by Donald Zoch
+		<donald.zoch@amd.com>.
+
+		Updated lsof for FreeBSD 6.0 and higher for a change in
+		<sys/vnode.h>, based on a report from Sergey A. Osokin
+		<osa@FreeBSD.ORG>.  Made the update available in a 4.74
+		'A' edition pre-release.
+
+		Filed an HP bug report about missing pstat(2) CWD info
+		for LOFS on HP-UX 11.11 and higher.  The missing CWD
+		info was noticed by Ermin Borovac <e.borovac@bom.gov.au>.
+		Added info to 00FAQ about the problem, which can cause
+		the lsof test suite's LTbasic test to fail.
+
+		Updated the q4-generated tcp_s.h in the lsof
+		distribution and added socket option support for HP-UX
+		11.00.  Erwin Reyns <ereyns@europarl.eu.int> helped
+		test.
+
+		Updated for Solaris 10, build s10_69, with a patch
+		supplied by Mike Miscevic <miscevic@hotpop.com>.
+
+		Added v_path support to Solaris 10 lsof.  That relieves
+		it of having to read and decode the kernel DNLC, and
+		delivers full paths more reliably.
+
+		Added specialized NFS4 support to Solaris 10 lsof.
+
+		Applied Solaris 10 patches to lsof supplied by Casper
+		Dik <casper@holland.sun.com>.
+
+		Updated lsof for NetBSD 2.99.10 and tested it on a
+		system provided by Andrew Brown <atatat@atatdot.net>.
+
+		Added support for the FreeBSD 6.0-CURRENT f_vnode
+		pointer in the file structure.
+
+		Added BSDI, FreeBSD, NetBSD and OpenBSD support for the
+		*effnlink member of the inode structure.  This makes
+		the lsof LTnlink test run faster on all modified
+		dialects and correctly on OpenBSD.
+
+		Added ptyfs support for NetBSD, using modifications
+		provided by Andrew Brown.
+		
+		Changed the netbsd Configure stanza to look by default
+		for system header files in both /usr/include and
+		/usr/src.  (The NETBSD_SYS environment variable can
+		still be used to select an alternate for /usr/src.)
+
+		Corrects two FreeBSD 4.10 RPC/XDR type definitions.
+
+		Added an FAQ Q&A about setuid and setgid restrictions
+		in HP-UX 11.11.  The information in the answer was
+		supplied by Frank Sanders <frank.sanders@siemens.com>.
+
+		Added abbreviations for AXI FCIO and FSNAPSHOT file
+		flags.  Holger VanKoll <Holger.VanKoll@swisscom.com>
+		reported the missing FCIO.
+
+		Adjusted lsof's private AIX 64 bit rnode structure for
+		64 bit AIX 5.2 systems.  (IBM doesn't distribute a
+		correct <nfs/rnode.h> for it.)
+
+		Corrected a Linux socket inode printing bug reported by
+		Igor Schein <igor@txc.com>.
+
+		Updated for FreeBSD 4.11.  The support compiles but
+		hasn't been tested.
+
+		Back-ported a FreeBSD 6.0-CURRENT fix to FreeBSD
+		5.3-RELEASE-p1.  That was done to solve a compilation
+		problem reported by Radko Keves <rado@daemon.sk>.
+
+4.75		May 16, 2005
+		Dropped the *claim* that lsof works on DEC OSF/1 and
+		Digital UNIX, since my last 4.0 test system has been
+		removed.  The last tested distribution of lsof on DEC OSF/1
+		and Digital UNIX was revision 4.74.  It has been archived
+		on lsof.itap.purdue.edu in pub/tools/unix/lsof/OLD/src.
+
+		Added negation forms to the values in the -g (PGID) and
+		-p (PID) lists.  Negated PGID and PID values, like
+		negated UID or login name values, are applied without
+		ORing or ANDing and take effect before any other
+		selection criteria are applied.
+
+		At the request of Marcin Gozdalik <gozdal@gmail.com>
+		added a -X option for Linux.  The option inhibits the
+		reading of the /proc/net/tcp* and /proc/net/udp*
+		files.
+
+		Based on a report from David Gutierrez
+		<davegu1@hotmail.com> changed DEC OSF/1 process table
+		allocation to request memory in smaller increments.
+
+		Based on a report from jayjwa <jayjwa@atr2.ath.cx>
+		updated the Customize script to use "tail -n 1" where
+		possible.
+
+		Enabled support for FreeBSD 5.4.
+
+		Improved the BSDI, FreeBSD, NetBSD, OpenBSD and Solaris
+		kvm_open() and kvm_openfiles() error messages.
+
+		Enabled support for NetBSD 2.99.12.
+
+		Improved HP-UX Configure stanza with help from Piet
+		Starreveld <pstarrev@csc.com>.  Picked some lint Piet
+		found.
+
+		Enabled IPv6 support for HP-UX > 11.  Piet Starreveld
+		helped test it on 11.23, among others.
+
+		Updated for HP-UX 11.23 on the ia64 architecture.
+
+		Updated to latest FreeBSD 6.0-CURRENT, using a test
+		system provided by Andrzej Tobola <ato@iem.pw.edu.pl>.
+
+		Added support for SCO OSR 6.0.0 and UnixWare 7.1.4 with
+		help from Richard at SCO.
+
+		Corrected a Linux bug in NFS handling, reported by Karel Zak
+		<kzak@redhat.com>.  Karel supplied a patch.
+
+		Improved the code for accessing an AIX 3.2 and higher
+		sockaddr_un structure, thus eliminating a segmentation
+		fault possibility.
+
+		Updated for AIX 5.3.
+
+		Added preliminary (DEBUG) support for the AIX SANFS
+		file system.
+
+		Fixed a bug in the Solaris 10 processing of the vnode's
+		v_path pointer with code supplied by Edward Jajko
+		<ejajko@portal.com>.  The fix was offered as a patch to
+		4.74.
+
+		Dropped support for OpenUNIX 8, since a test system is
+		no longer available.  Archived an OpenUNIX-only
+		distribution of the last revision (4.74) tested on
+		OpenUNIX in pub/tools/unix/lsof/OLD/src.
+
+		Tested under Openbsd 3.7.
+
+		Tested under Darwin 7.7.0.
+
+		Enabled building on amd64 Solaris 10 with hints from
+		Marc Aurele La France <tsi@ualberta.ca>.  Marc provided
+		a test system.
+
+		Supplied a missing quote in the FreeBSD Configure
+		stanza.  Carl Cook <Info@quantum-sci.com> reported the
+		problem.
+
+		Removed "-O" option from tests/Makefile so that the
+		HP-UX bundled compiler won't complain.
+
+4.76		August 30, 2005
+		Corrected an example and spelling errors in man page.
+
+		Updated for Apple Darwin 8.x with changes supplied by
+		Allan Nathanson <ajn@apple.com>.  Allan also provided a
+		test system.
+
+		Completed documentation of CLRLFILEADD in all machine.h
+		files.
+
+		At the request of Chris Markle <cmarkle@sendmail.com>
+		added partial listen queue length to socket options
+		displayed when -Tf is specified.  Partial queue length
+		is not reported for all dialects.  (00FAQ lists the
+		ones where it is reported.)
+
+		Updated for FreeBSD 7.0 with information supplied by
+		Andrzej Tobola <ato@iem.pw.edu.pl>.
+
+		Updated Solaris VxFS support for VxFS versions 4 and
+		above with technical advice from Craig Harmer
+		<craig_harmer@symantec.com>, Gary Millen
+		<gary_millen@symantec.com> and Chuck Silvers
+		<charles_silvers@symantec.com>.  Testing help was
+		provided by Michael Antlitz <mantlitz@prophasys.com>,
+		Steve Ginsberg <steve@dhapdigital.com> and Kenneth
+		Stailey <kstailey@yahoo.com>.
+
+		Fixed a Solaris address space map processing bug.
+		Janardhan Molumuri <mjanardhan@gmail.com> reported the
+		bug and help me identify it.  Made the fix available as
+		a patch to 4.75.
+
+		Added support for Solaris 10 port and CTFS files.  The
+		CTFS support is imcomplete, because I don't know how
+		to get inode number, size and link count.  (There's
+		a new 00FAQ entry about that.)
+
+		Investigated a report from Christopher J Warweg
+		<warwegc@GAO.GOV> that the CHECKSUMS for the lsof 4.75
+		binary for 64 bit Solaris 8 was incorrect.  It was my
+		packaging error.  I rebuilt and repackaged the binary.
+
+		Enabled support for Linux map file names with embedded
+		spaces.
+
+4.77		April 10, 2006
+		Added -X option support for Solaris 10 and above.  When
+		-X is specified lsof will report cached v_node path
+		names for unlinked files, followed by "(deleted)".
+		Improved cached vnode path name handling by adding
+		"(?)" to the end of path names of questionable accuracy.
+		Updated 00FAQ to reflect these changes.
+
+		Updated for FreeBSD 7.0-CURRENT.
+
+		Fixed name addition spacing bug, reported by Stuart
+		Anderson <anderson@ligo.caltech.edu>.  Also updated
+		Solaris 10 SAMFS support at Stuart's request.
+
+		Added missing "break;" and another HASSTATVFS test to
+		the NetBSD and OpenBSD dnode.c.  Bill Behr
+		<bbehr@networkstoragecorp.com> reported those needs.
+
+		Fixed an HP-UX 11 file descriptor "chunk" size problem,
+		reported by Per Allansson <per@appgate.com>.  Per helped
+		devise the fix and tested it.  This fix was offered as
+		a patch to lsof 4.76.
+
+		Updated for FreeBSD 6.0-STABLE and FreeBSD
+		6.1-PRERELEASE.
+
+		Updated scripts/sort_res.perl5 with changes supplied by
+		Frederick Fabian <fabian.frederick@skynet.be>, the
+		author of the script.
+
+		Corrected +|-M man page documentation error, reported
+		by Roger Cornelius <rac@tenzing.org>.
+
+		Improved FreeBSD user device random seed generation in
+		response to a problem report from Danny Braniss
+		<danny@cs.huji.ac.il>.
+
+		Eliminated three syntax error bugs and other compiler
+		complaints from the PSTAT-based lsof.  H. Merijn Brand
+		<h.m.brand@xs4all.nl> reported the problems and tested
+		the fixes.
+
+		Eliminated compiler complaints in the test suite.
+
+		Investigated problems with the building of lsof on
+		PA-RISC HP-UX 11.23, based on a report from John
+		Orndorff <John.Orndorff@sungard.com>.  Found that
+		neither the HP bundled C compiler nor gcc would build
+		lsof, but the the HP unbundled ANSI C compiler would.
+		Concluded that HP bundled C compiler can't handle
+		<gssapi/gssapi.h>.  Devised a work-around to gcc's
+		omission of the rpcent structure definition of
+		<netdb.h> that allows it to compile lsof's print.c, but
+		the resulting binary doesn't run reliably.  Documented
+		the situation in 00FAQ.
+
+		Changed reporting of unknown file types.  The number of
+		an unknown type is now reported as four octets.  The
+		change was made in response to a Linux lsof bug report
+		from Karel Zak <kzak@redhat.com>.
+
+		Dropped the *claim* that lsof works on BSDI BSD/OS
+		since my last test system has been removed.  The last
+		tested distribution of lsof for BSDI BSD/OS was
+		revision 4.76.  It has been archived on
+		lsof.itap.purdue.edu in pub/tools/unix/lsof/OLD/src.
+
+		As a result of discussing the lsof source tar's MD5
+		checksum with Andrew Bell <andrew.bell.ia@gmail.com>,
+		changed the description of a suitable MD5 tool in the
+		lsof distribution's documentation to name the openssl
+		"dgst" command.
+
+		Enabled compilation on Solaris 10 1/06 with a fix sent
+		by Jason Fortezzo <fortezza@mechanicalism.net>.  Made
+		the fix available as a patch to 4.76.
+
+		Adjusted to FreeBSD 5.5-PRERELEASE.
+
+		Corrected a bug in the lsof library's process_file()
+		function to enable the locating of AIX XTI sockets by
+		their TCP/IP address values.  The bug was reported by
+		Michel Dubois <Dubois@sears.ca>.
+
+		Based on a bug report from Karel Zak <kzak@redhat.com>
+		added command name length checking to as many dialects
+		as possible (Linux for Karel) for the "-c c" option.
+
+		Updated for OpenBSD 3.[89].  Tested the 3.9 update on a
+		system provided by David Mazieres.  I have not tested
+		on OpenBSD 3.8, but David reports lsof 4.76 worked
+		there.
+
+		Ended regression testing of lsof on 32 bit Solaris 8
+		with the ending of access to a test system.  Lsof
+		continues to be tested on 64 bit Solaris 8.
+
+4.78		April 24, 2007
+		Added more information to the lsof FAQ about missing
+		link counts and sizes on Linux files.
+
+		Simplified Linux stat() and lstat() usage.
+
+		Relocated #define's that prevent OpenBSD compilation on
+		systems without a /proc file system.  Pieter Bowman
+		<bowman@math.utah.edu> reported the problem.
+
+		Added code to avoid processing Linux /proc/<PID>/maps
+		file entries with zero device and node numbers.  Some
+		such entries now have names associated with them that
+		are not path names -- e.g., "[heap]", "[stack]" or
+		"[vdso]".  Scott Worley <sworley@chkno.net> reported
+		lsof's mishandling of such entries.
+
+		Added SELinux security context support, provided by
+		James Antill <james.antill@redhat.com>.  I have not
+		tested this, but James and Karel Zak <kzak@redhat.com>
+		have.
+
+		Added the #include of <sys/types.h> to Solaris lsof to
+		enabled compilation on Solaris 10 6/06.  Peter Harvey
+		Peter.Harvey@Sun.COM diagnosed the problem and supplied
+		a patch.
+
+		Added better support for JFS2 on AIX 5.2 and 5.3, based
+		on bug reports and help from Thomas Braunbeck
+		<BRAUNBEC@de.ibm.com> and Tom Whitty <TWHITTY@cerner.com>.
+
+		Documented that lsof supports AIX 5.3 only up through
+		maintenance level 1 (ML1).
+
+		Enabled Solaris lsof to locate the AFS vnode operation
+		address for OpenAFS 1.4.1.  The fix was supplied by
+		Robert Jelinek <Robert.Jelinek@MorganStanley.com>.
+
+		Enabled support for Solaris 10 ZFS.  If the necessary
+		ZFS header files aren't found, lsof offers the option
+		to drop ZFS support, to use internal, possibly
+		inaccurate structure definitions, or to supply a path
+		to the missing header files.  Horst Scheuermann
+		<Horst.Scheuermann@uni-trier.de> provided a development
+		system and helped test the support.
+
+		Corrected a typo in the man page, reported by Eric S.
+		Raymond <esr@thyrsus.com>.
+
+		Changed the spelling of macroes to macros in lsof
+		source and documentations files, based on a suggestion
+		from Josh Soref <timeless@gmail.com> and verification
+		with the OED.
+
+		The following dialects are no longer supported: 32 bit
+		AIX 5.2, HP-UX 11, OpenStep 4.2, Solaris 2.6, Solaris
+		8, True Unix 64 and UnixWare 7.1.4.  Lsof may work on
+		them, but I no longer have test systems for them.
+		Support for OpenBSD ends at its version 3.9 for lack of
+		interest in the port.
+
+4.79		April 15, 2008
+
+		**************** IMPORTANT NOTE ******************
+		*                                                *
+		* Lsof support has been reduced to the following *
+		* dialects: AIX, FreeBSD, Linux and Solaris, and *
+		* only in selected versions of those dialects.   *
+		* The selected versions are listed in this file  *
+		* and in other lsof documentation.               *
+		*                                                *
+		* I have made this move because of retirement    *
+		* and because I no longer have many test systems *
+		* available to me.                               *
+		*                                                *
+		* Vic Abell                                      *
+		*                                                *
+		**************************************************
+
+		Fixed a Solaris VXFS permission problem when accessing
+		the VXFS inode offsets.  The bug was reported by
+		Gregory A. Ivanov <ivga@mts.ru>.  Gregory tested the
+		fix.
+
+		Moved an #include <string.h> later in FreeBSD dlsof.h
+		to enable compilation on recent FreeBSD releases.  The
+		change was supplied by Roy Marples <uberlord@gentoo.org>.
+
+		Improved Linux /proc file stream reading speed by applying
+		an expanded version of a patch from Eric Dumazet
+		<dada1@cosmosbay.com> that allocates a page size buffer
+		to each stream.  Improved TCP, TCP6, UDP and UDP6 hashing
+		by determining the hash bucket count from the /proc/net
+		sockstat and sockstat6 files.  The improvement was
+		suggested by Eric and he provided sample code.  Eric also
+		tested both improvements.
+
+		Modified Configure script to build lsof on FreeBSD
+		6.2.  Tested it on a system provided by Larry Rosenman
+		<ler@lerctr.org>.
+
+		Fixed a Linux maps file processing bug that prevented path
+		names from having an embedded colon.  James Lingard
+		<jchl@arastra.com> reported the bug and helped with its
+		fix.
+
+		Based on reports from Eric Dumazet and Samuel Thibault
+		<samuel.thibault@ens-lyon.org> added support for the
+		Linux 2.6.22 kernel's /proc/<PID>/fdinfo files -- i.e.,
+		file offset and flags.  Samuel Thibault provided a test
+		system.
+
+		Fixed a Linux UNIX socket memory leak, reported by
+		Philip Shin <pshin@xceedium.com>.  Phillip supplied the
+		fix.
+
+		With generous assistance from HP added support for an HP-UX
+		11.23 patch that makes TLI/XTI socket address information
+		available.
+
+		Fixed a header file problem for FreeBSD 6.2 on the Alpha
+		architecture.  The problem was reported by Pekka Honkanen
+		<phonkane@cc.hut.fi>.  Pekka tested the fix.
+
+		Based on a report and using suggested fixes from Karel Zak
+		<kzak@redhat.com>, made these changes to Linux lsof: corrected
+		a getpidcon() error message; insured that inode numbers are
+		handled correctly for their unsigned long long type; and
+		improved SELinux handling.  At the request of Alon Bar-Lev
+		<alonbl@gentoo.org> added the LINUX_HASSELINUX environment
+		variable to enable or inhibit SElinux support unconditionally.
+
+		Updated Configure for FreeBSD 8.0-CURRENT and tested lsof on
+		AMD64 there.
+
+		Added a patch provided by Oles Hnatkevych
+		<don_oles@able.com.ua> for FreeBSD systems where the root
+		file system is on a CD9660 device.
+
+		Added compensation for the disappearance of FMARK and FDEFER
+		from the FreeBSD 8.0-CURRENT <sys/file.h>.
+
+		Updated FreeBSD lsof with ZFS support.  Larry Rosenman
+		<ler@lerctr.org>, Erwin Lansing <erwin@FreeBSD.org>, Wesley
+		Shields <wxs@atarininja.org> and Dmitry Morozovsky
+		<marck@rinet.ru> provided test systems.
+
+		Fixed a socket file identification problem reported by
+		Pavol Rusnak <stick@gk2.sk>.  Pavol also reported the
+		cause of the problem.
+
+		Added the ability to format the repeat mode marker line
+		with strftime(3), where the dialect supports the
+		localtime(3) and strftime(3) C library functions.  The
+		addition was suggested by Mike Depot <mdepot@comcast.net>,
+		who also tested it.  The addition required creating a new
+		main lsof source module, util.c, that contains functions
+		whose compilation conflicts with the general header file
+		tree defined by lsof.h and dlsof.h.
+
+		Based on reports from Andrei V. Lavreniyuk
+		<andy.lavr@reactor-xg.kiev.ua> and Pav Lucistnik
+		<pav@FreeBSD.org> updated the FreeBSD 7.0 and above
+		file lock handling to use new locking structures.  The
+		update requires a terrible hack to get a definition for
+		the lock owner structure from a kernel source module
+		into a local lsof header file.
+
+4.80		May 12, 2008
+		Updated for a FreeBSD 7.0 and above byte level locking
+		change.  The problem was reported by Conrad J. Sabatier
+		<conrads@cox.net>, who helped test the update.  Wesley
+		Shields <wxs@FreeBSD.org> provided an 8.0-CURRENT test
+		system.
+
+		Propagated the FreeBSD 7.0 and above locking changes to
+		FreeBSD 6.x, based on a report from Edwin Groothuis
+		<edwin@FreeBSD.org>.
+
+		Added warnings for unsupported dialects or versions.
+
+		Added Linux support for the UDPLITE protocol.  Eric
+		Dumazet <dada1@cosmosbay.com> supplied a patch.
+
+		Added a missing quote to the Configure script's
+		FreeBSD stanza.
+
+		Added a usage.o rule to the HP-UX PSTAT-based
+		Makefile.  I mistakenly deleted the rule at revision
+		4.79.  The missing rule was reported by Kawaljeet Kaur
+		<kawaljeet.malviya@gmail.com> who tested the corrected
+		Makefile.
+
+4.81		October 21, 2008
+		Updated the Darwin libproc sources with changes from
+		Allan Nathanson <ajn@apple.com>.  Tested them on a iMac
+		mini, provided by Apple Inc.
+
+		Changed dummy declarations in library source files to
+		eliminate complaints about unused variables and empty
+		object files.  This change may not work on dialects I
+		can no longer test; it has been tested on some versions
+		of AIX, Darwin, FreeBSD, Linux and Solaris.
+
+		At the request of Hal Brooks <hal@uga.edu> added support
+		for Linux /proc/net/packet files.  Hal tested it.
+
+		Added socket file only performance enhancements to Linux
+		and PSTAT-based HPUX lsof.
+
+		Added htonl call around improper usage of INADDR_LOOPBACK;
+		report from an Apple engineer forwarded by Allan Nathanson
+		<ajn@apple.com>.
+
+		Adjusted for FreeBSD-8.0 change in device number handling.
+		The adjustment should work for FreeBSD 5 and above, should
+		the 8.0 change be propagated downward.  The problem was
+		reported by Pav Lucistnik <pav@FreeBSD.org>.  An updated
+		test system was provided by Erwin Lansing <erwin@FreeBSD.org>.
+
+		Reduced AIX support to version 5.3, since test systems with
+		older versions are no longer available to me.
+
+		At the request of Marjo F. Mercado <mmercado@xceedium.com>
+		and Phil Shin <pshin@xceedium.com> applied some speed
+		improvements to lsof, particularly when the files of
+		interest are /Internet files -- i.e., selected with lsof's 
+		"-i" option.  Added a two new options to assist the
+		improvements: 1) "-c^<command>" to tell lsof to exclude the
+		named command(s); and 2) "-stcp|ud>:[^]state' to tell lsof
+		to include in its reporting or exclude ('^') from its
+		reporting Internet files in the named states (e.g., LISTEN,
+		^CLOSE_WAIT, IDLE, etc.)  For the most part these changes
+		apply only to AIX, Darwin, FreeBSD, PSTAT-based HP-UX, Linux
+		and Solaris, since those are the only places I could test
+		them.  They are controlled by the HASTCPUDPSTATE definition
+		in each dialect's machine.h header file.  Marjo and Phil
+		provided HP-UX 11.23 and 11.31 test systems.
+
+		Fixed a stat(2) problem on HP-UX 11.31 while testing the
+		speed improvements.
+
+		Adjusted for kernel header file changes in FreeBSD
+		8.0-CURRENT.  Larry Rosenman <ler@lerctr.org> provided
+		a test system.
+
+		Added a warning for Solaris systems where VxFS node info
+		can't be obtained from the VxFS utility library.  The
+		warning was requested by Tom Matthews <Tom.MATTHEWS@rbs.com>.
+
+		Corrected mishandling of file system path name arguments
+		that have trailing slashes, except, of course, the root
+		file system, "/".  Allan Nathanson <ajn@apple.com> reported
+		the bug.
+
+4.82		March 25, 2009
+		Corrected an over-zealous exclusion test that caused
+		lsof to report nothing when it was given no arguments
+		and built with HASSECURITY and HASNOSOCKSECURITY enabled.
+		Joshua Kinard <kumba@gentoo.org> reported the bug and
+		supplied information for reproducing it.
+
+		Based on a report from Dan Trinkle <trinkle@cs.purdue.edu>
+		corrected use of <sys/utsname.h> for 32 bit Solaris 10
+		and above compilations.  Simultaneously eliminated a
+		casting complaint in arg.c and updated Configure to use
+		the appropriate 64 bit compilation option (-xarch=v9 or
+		-m64) with the Solaris Sun C compiler.
+
+		Updated for FreeBSD 7.1-PRERELEASE with information
+		supplied by Larry Rosenman <ler@lerctr.org>.
+
+		Updated the Darwin libproc sources with changes from
+		Allan Nathanson <ajn@apple.com>.  Tested them on a iMac
+		mini, provided by Apple Inc.  Allan also provided man
+		page corrections.
+
+		Updated the FreeBSD Makefile to use the ${MAKE} variable
+		for ZFS dnode2.c module compilation, based on a suggestion
+		from Alexis Ballier <aballier@gentoo.org>.
+
+		Improved the Solaris VxFS library location test, based on a
+		suggestion from Jason Fortezzo <fortezza@mechanicalism.net>.
+		Jason tested the change.
+
+		Updated Solaris 10 ZFS support for ZFS version 4 and ZFS
+		pool version 10, using a test system kindly provided by
+		Vladislav Nespor <vladislav.nespor@id.ethz.ch>.  Renata
+		Maria Dart <renata@slac.stanford.edu> tested on ZFS
+		version 4, verifying that the update works there, too.
+		(ZFS pool version 10 is apparently the ZFS version shipped
+		with the 10/08 update to Solaris.  The original ZFS
+		support targeted ZFS version 3.)
+
+		I still consider ZFS support in Solaris lsof a hack,
+		because it depends on a znode structure definition that
+		I developed using dbx.  Sun is remiss in not distributing
+		the ZFS header files used to build the distributed kernel.
+
+		Because of the znode structure definition hack, I can't
+		guarantee that lsof ZFS support will work for any other
+		versions of ZFS.
+
+		Solaris 10: adjusted to a change in the way devices are
+		stored in the kernel; fixed a problem in zone handling;
+		and added rudimentary sharedfs support.  Carson Gaspar
+		<carson@taltos.org> reported the device number problem,
+		provided a test system, and tested the changes.  Peter
+		Vines <psv2b@eservices.virginia.edu> reported the zone
+		handling problem and tested the fix.
+
+		Adapted to FreeBSD 8.0-CURRENT changes in device number
+		computation.  Problem was reported by Erwin Lansing
+		<erwin@FreeBSD.org>.  Larry Rosenman <ler@lerctr.org>
+		provided a test system.
+
+		Corrected Solaris Configure test for appropriate VxFS
+		library when using gcc to compile lsof.
+
+		Updated for loss of KAME IPv6 FreeBSD accommodations.
+
+		Adapted to FreeBSD 7.2.  Made Configure script recognized
+		FreeBSD 6.3.
+
+4.83		January 18, 2010
+		Converted Solaris 10 and above ZFS support to use the CTF
+		debugger library, libctf.  Code was supplied by Robert
+		Byrnes <Robert.Byrnes@deshaw.com>.
+
+		Corrected a typo in the testing of the LINUX_HASSELINUX
+		environment variable in the Configure script.  The error
+		was reported by Mike Frysinger <vapier@gentoo.org>.
+		At Mike's request made Configure script accept LSOF_RANLIB
+		(ranlib command), LSOF_CFGF (additional configuration flags)
+		and LSOF_CFGL (additional library specifications) from the
+		environment.
+
+		Enabled complilation of Solaris 10 lsof after a recent Sun
+		patch which changed the PC file system's structure. Peter
+		Vernam <pvernam@draper.com> reported the problem and helped
+		with the fix.
+
+		Made the sort of configuration CFLAGS in the CkTestDB
+		script impervious to locale settings.
+
+		Ported to Solaris 11, using a test system kindly provided
+		by David Day <dday76@gmail.com>.
+
+		Adjusted to the disappearance of <nfs/rpcv2.h> in FreeBSD
+		8.0-BETA1.
+
+		Changed Solaris node type lookup to a hashed method and
+		added some ability for it to handle duplicate vnodeop names
+		in /dev/ksyms.
+
+		Updated for FreeBSD 9.0-CURRENT.  Andrzej Tobola
+		<ato@iem.pw.edu.pl> provided a test system.  Extends the
+		fix to FreeBSD 6.0 and above via a Configure test and a
+		compile-time definition.  The need for the extension was
+		reported by Erik Trulsson <ertr1013@student.uu.se>>
+
+		Made corrections to FAQ typographical errors, suggested
+		by Josh Soref <timeless@gmail.com>.
+		
+		Added __UCLIBC__ test to Linux dlsof.h so lsof would compile
+		on an Intel ARM XScale processor.  The addition was provided
+		by Doug Kehn <rdkehn@yahoo.com>.
+
+		Added test for <utmpx.h> to FreeBSD configuration.  Improved
+		its use in lsof.h.  The changes were supplied by Martin Wilke
+		<miwi@FreeBSD.org>.
+
+4.84		July 29, 2010
+		Fixed a man page nroff command error with a correction
+		supplied by Josh Soref <timeless@gmail.com>.
+
+		Made Configure script recognize FreeBSD 7.3.  Larry Rosenman
+		<ler@lerctr.org> provided a test system.
+
+		Improved task support, initially for Linux only, with help
+		provided by Jerome Marchand <jmarchan@redhat.com> and
+		Miklos Szeredi <mszeredi@suse.cz>.  The support includes a
+		new compile-time definition, HASTASKS, and a new run time
+		option, "-K" to select task reporting.
+
+		While adding help output support for "-K", reorganized the
+		printing of help columns to make it much easier to add a new
+		option description.
+
+		Updated the Solaris PC file system structure patch in
+		revision 4.83 so it will compile with gcc.
+
+		Disabled the Solaris lgrp_root work-around in the Solaris
+		machine.h so it won't cause compilation problems on Solaris
+		11.  It no longer causes compilation problems on my Solaris
+		9 and 10 test systems, but some older Solaris 9 and 10
+		versions may still need it, so the work-around was left in
+		the Sun machine.h and a FAQ entry was created about it.
+
+		Updated for Solaris 11 b134, using a test system kindly
+		provided by Carson Gaspar <carson@taltos.org>.  Made
+		provisions for the next ZFS version.  Added info about
+		the failure of the LTnlink test on ZFS file systems.
+
+		Corrected typo in Configure script, reported by Dmitry
+		Berezin <dmitryb@oit.rutgers.edu>.
+
+4.85		September 27, 2011
+		John Dzubera <Zube@CS.ColoState.EDU> kindly provided a patched
+		Solaris 9 test system with the lgrp_root conflict and I was
+		able to devise an automatic work-around for the conflict.  The
+		special note in .../dialects/sun/machine.h was removed and
+		the 17.28.1 FAQ entry was modified to reflect the update.
+
+		Added a Solaris 11 work-around for a typedef problem with
+		<sys/mutex.h>.  Carson Gaspar <carson@taltos.org> reported
+		the problem and supplied the work-around.
+
+		Added support for FreeBSD 7.4 and 8.2; tested on systems
+		provided by Larry Rosenman <ler@lerctr.org>.
+
+		Added support for 32 bit Solaris 11 lsof with mods supplied
+		by Jan Wortelboer <J.H.P.Wortelboer@uva.nl>.
+
+		Added Solaris 11 support for using an alternate genunix
+		location.  Bill Goodridge <bill@its.brooklyn.cuny.edu>
+		reported the alternate location.
+
+		Added further Linux cross configuration support to lsof's
+		Configure script.  The additional support was supplied by
+		Grant Erickson <erick205@umn.edu>.  See the descriptions of
+		the LINUX_* environmen  variables in 00XCONFIG for more
+		information.  Tested lsof on Linux kernel 2.6.32 and picked
+		some lint that surfaced during the test.
+
+		Added fixes and changes for Apple Mac OS X 10.6, provided by
+		Allan Nathanson <ajn@apple.com>.  Allan also provided a test
+		system.
+
+		Tested on FreeBSD 6.4 i386, using a test system provided by
+		Terry Kennedy <TERRY@tmk.com>.  Updated for recent FreeBSD ZFS
+		changes on an 8.2 amd64 test system also provided by Terry.
+
+		Changed documentation to indicate FreeBSD 7.x is no longer
+		supported, since I no longer have a test system.
+
+		Made some changes to the lsof man page, suggested by Navid
+		<evi1m4chine@googlemail.com>.
+
+		Added compensation for Solaris 10 systems that have patch
+		144488-10.  The patch requires that the new header file
+		<sys/socket_proto.h> be included while _KERNEL is defined.
+		Brett Bartick <Brett.bartick@nomura.com> reported the problem
+		first, followed by Stuart Anderson <anderson@ligo.caltech.edu>.
+		Michael Hocke <michael.hocke@nyu.edu> suggested a work-around
+		which I refined to limit it to the specific Solaris 10 instance
+		and then tested on a system provided by Charles Stephens
+		<cfs@cowlabs.com>
+
+		Added the +|-e option for Linux.  It exempts file systems
+		named by path from function calls that might block in the
+		kernel -- i.e., stat(2) and lstat(2), and when the +e form
+		is used, readlink (2).  The new packager of lsof for the
+		Linux Fedora and RHEL distributions, Peter Schiffer
+		<pschiffe@redhat.com>, asked for the feature so it could
+		be used with Clearcase file systems, whose implementation
+		can block stat(2) calls.  I consider this feature very risky
+		and easy to misuse -- e.g., specifying the file system as
+		'/' would exempt all file systems.  I don't intend to
+		propagate this option to any other UNIX dialect that lsof
+		currently supports.
+
+		Made FreeBSD 9 adjustment.
+
+		Fixed a Linux bug that prevented the display of paths for
+		abstact UNIX sockets.  Masatake Yamato <yamato@redhat.com>
+		reported the bug and supplied a patch.
+
+		Added compensation for the removal of RPC header files from
+		GlibC 2.14 for Linux.  Marek Behun <kabel@blackhole.sk>
+		reported the problem and supplied a patch.
+
+		Added support for Linux Netlink protocol.  Masatake Yamato
+		requested the support and supplied a patch.  Peter Schiffer
+		<pschiffe@redhat.com> provided a test system.
+
+		Corrected Linux UDP6-lite path.  The error was reported by
+		Masatake Yamato and he also supplied a patch.
+
+4.86		April 10, 2012
+		Lsof for AIX is no longer supported on any versions of that
+		operating system.
+
+		Added information about the clang compiler for FreeBSD to the
+		FAQ.
+
+		Corrected an arg.c bug in the accumulation of +|-e option
+		values, reported by Peter Schiffer <pschiffe@redhat.com>.
+		This correction was supplied as a patch to revision 4.85.
+
+		Enabled FreeBSD 10 support and tested it there on a system
+		provided by Larry Rosenman <ler@lerctr.org>.
+
+		Updated for latest Solaris 11 with patches supplied by
+		Carson Gaspar <carson@taltos.org>.  Carson supplied a test
+		system.
+
+		Adjusted Linux file system search method to compensate for
+		NFS mounts that have duplicate device numbers.  The problem
+		was reported by Peter Schiffer <pschiffe@redhat.com>, who
+		provided a test system.
+
+		At the request of Peter Schiffer <pschiffe@redhat.com>, added
+		support for Linux SCTP socket files.  Peter provided a test
+		system.  Applied a warning patch supplied by Peter.
+
+		Added support for Mac OS X 10.7 (Lion), provided by Allan
+		Nathanson <ajn@apple.com>.  Allan also supplied a test
+		system.
+
+		Enabled FreeBSD 8.3 support and tested it there on a system
+		provided by Larry Rosenman <ler@lerctr.org>.
+
+		Corrected the FAQ information on ZFS with Solaris 10 after
+		Steven Blackmon <stblackm@cisco.com> and Prasad Jampala
+		<jampalp@cisco.com> pointed out that it was incorrect --
+		i.e., outdated by the libctf changes at revision 4.83.
+
+		Added code to handle a Linux NFS-mounted root.  Jia He
+		<hejianet@linux.vnet.ibm.com> reported the need for this.
+
+4.87		January 2, 2013
+		Added an entry to 00FAQ about lsof behavior when the
+		HASSECURITY and HASNOSOCKSECURITY options are defined.
+		Carson Gaspar <carson@taltos.org> pointed out the need
+		for this clarification.
+
+		Added a work-around for a missing definition of mach_port_t
+		in Darwin 9 (Mac OS/X 10.5.8).  The work-around was supplied
+		by Jim Reid <jim@rfc1035.com>.
+
+		Added support for Linux anon_inodefs, provided by Masatake
+		YAMATO <yamato@redhat.com>.
+
+		Documented a Solaris 9 and 10 portmap reporting problem
+		(+M) in 00FAQ.  The problem was reported by Clint
+		Roberts <Clint.Roberts@ttius.com>.  I have no solution
+		to the problem, but discuss a possible work-around in
+		the answer to this 00FAQ question: "Why doesn't lsof
+		report portmap registrations for some Solaris versions?"
+
+		Added FreeBSD support for the oldnfs and newnfs file system
+		types.  Daniel Braniss <danny@cs.huji.ac.il> reported the
+		need for the addition.
+
+		Added ICMP socket support for Linux with code provided by
+		Masatake YAMATO <yamato@redhat.com>.
+
+		Corrected the reporting of process group ID for libproc
+		versions of Mac OS X with a patch from Jeff Trawick
+		<trawick@gmail.com>.  The patch has not been applied to
+		Darwin kmem versions, because of little call for them
+		and inadequate test system access.  The patch has been
+		tested on Mac OS X 10.8 (Mountain Lion), courtesy of a
+		test system provided by Allan Nathanson <ajn@apple.com>.
+
+		Added thread support to those FreeBSD versions that have
+		ki_numthreads in their kinfo_proc structure.  This also
+		activates the -K option for those FreeBSD versions.  Jeff
+		Trawick reported problems with FreeBSD lsof when threads
+		are present and this addition solves those problems.
+
+		Made changes to 00FAQ and the distribution, suggested by
+		Warren Young <warren@etr-usa.com>.  The 00FAQ changes
+		center on sections that discuss the -s option.  The changes
+		to the distribution include a ChangeLog file that is either
+		a pointer to or a copy of 00DIST, the distribution notes.
+
+		Added support to FreeBSD for using the clang compiler.
+
+		Added Linux support for using the getxattr() call to obtain
+		socket protocol identification when it is can't be obtained
+		from the /proc/net files that lsof examines.  Masatake YAMATO
+		<yamato@redhat.com> developed the kernel patch to getxattr()
+		and supplied the lsof patch.
+
+Vic Abell <abe@purdue.edu>
+January 2, 2013
diff --git a/00FAQ b/00FAQ
new file mode 100644
index 0000000..c75ae9f
--- /dev/null
+++ b/00FAQ
@@ -0,0 +1,8036 @@
+
+		Frequently Asked Questions about lsof
+
+**********************************************************************
+| The latest release of lsof is always available via anonymous ftp   |
+| from lsof.itap.purdue.edu.  Look in pub/lsof.README for its        |
+| location.                                                          |
+**********************************************************************
+
+______________________________________________________________________
+
+This file contains frequently asked questions about lsof and answers
+to them.
+
+Vic Abell <abe@purdue.edu>
+January 3, 2013
+______________________________________________________________________
+
+Table of Contents:
+
+1.0	General Concepts
+1.1	Lsof -- what is it?
+1.2	Where do I get lsof?
+1.2.1	Are there mirror sites?
+1.2.2	Are lsof executables available?
+1.2.3	How do I check the validity of an lsof distribution?
+1.2.4	Why can't I get the sum(1) result reported in
+	README.lsof_<revision>?
+1.2.5	Why won't gpg accept the lsof-signing PGP public key?
+1.3	Where can I get more lsof documentation?
+1.4	How do I report an lsof bug?
+1.5	Where can I get the lsof FAQ?
+1.5.1	How timely is the on-line FAQ?
+1.6	Is there a test suite?
+1.7	Is lsof vulnerable to the standard I/O descriptor attack?
+1.8	Can I alter lsof's make(1) behavior?
+1.9	Is there an lsof license?
+1.10	Language locale support
+1.10.1	Does lsof support language locales?  How do I use the support?
+1.10.2	Does lsof support wide characters in language locales?
+1.11	Are any files in the lsof distribution copyrighted?
+1.12	Are there other lsof-related resources?
+1.13	What does the "WARNING: unsupported dialect or version" mean?
+
+2.0	Lsof Ports
+2.1	What ports exist?
+2.2	What about a new port?
+2.2.1	User-contributed Ports
+2.3	Why isn't there an AT&T SVR4 port?
+2.4	Why isn't there an SGI IRIX port?
+2.5	Why does lsof's Configure script report "WARNING: unsupported
+	dialect or version"?
+
+3.0	Lsof Problems
+3.1	Configuration Problems
+3.1.1	Why can't Configure determine the UNIX dialect version?
+3.2	Compilation Problems
+3.2.1	Why does the compiler complain about missing header files?
+3.2.2   Why does gcc complain about the contents of header files
+	distributed by the system's vendor?
+3.2.3	Other header file problems
+3.3	Why doesn't lsof report full path names?
+3.3.1	Why do lsof -r reports show different path names?
+3.3.2	Why does lsof report the wrong path names?
+3.3.3	Why doesn't lsof report path names for unlinked (rm'd) files?
+3.3.4	Why doesn't lsof report the "correct" hard linked file path
+	name?
+3.3.5	When will lsof report path names for deleted files?
+3.4	Why is lsof so slow?
+3.5	Why doesn't lsof's setgid or setuid permission work?
+3.6	Does lsof have security problems?
+3.7	Will lsof show remote hosts using files via NFS?
+3.8	Why doesn't lsof report locks held on NFS files?
+3.8.1	Why does lsof report a one byte lock on byte zero as a full
+	file lock?
+3.9	Why does lsof report different values for open files on the
+	same file system (the automounter phenomenon)?
+3.10	Why don't lsof and netstat output match?
+3.10.1	Why can't lsof find accesses to some TCP and UDP ports?
+3.11	Why does lsof update the device cache file?
+3.12	Why doesn't lsof report state for UDP socket files?
+3.13	I am editing a file with vi; why doesn't lsof find the file?
+3.14	Why doesn't lsof report TCP/TPI window and queue sizes for my
+	dialect?
+3.14.1	Why doesn't lsof report socket options, socket states, and TCP
+	flags and values for my dialect?
+3.14.2	Why doesn't lsof report the partial listen queue connection
+	count for my dialect?
+3.15	What does "no more information" in the NAME column mean?
+3.16	Why doesn't lsof find a process that ps finds?
+3.17	Why doesn't -V report a search failure?
+3.18	Portmap problems
+3.18.1	Why isn't a name displayed for the portmap registration?
+3.18.2	How can I display only portmap registrations?
+3.18.3	Why doesn't lsof report portmap registrations for some ports?
+3.18.4	Why doesn't lsof report portmap registrations for some Solaris
+	versions?
+3.19	Why is `lsof | wc` bigger than my system's open file limit?
+3.20	Why doesn't lsof report file offset (position)?
+3.20.1	What does lsof report for size when the file doesn't really have
+	one?
+3.21	Problems with path name arguments
+3.21.1	How do I ask lsof to search a file system?
+3.21.2	Why doesn't lsof find all the open files in a file system?
+3.21.3	Why does the lsof exit code report it didn't find open files
+	when some files were listed?
+3.21.4	Why won't lsof find all the open files in a directory?
+3.21.5	Why are the +D and +d options so slow?
+3.21.6	Why do the +D and +d options produce warning messages?
+3.22	Why can't my C compiler find the rpcent structure definition?
+3.23	Why doesn't lsof report fully on file "foo" on UNIX dialect
+	"bar?"
+3.24	Why do I get a complaint when I execute lsof that some library
+	file can't be found?
+3.25	Why does lsof complain it can't open files?
+3.26	Why does lsof warn "compiled for x ... y; this is z."?
+3.27	How can I disable the kernel identity check?
+3.28	Why don't ps(1) and lsof agree on the owner of a process?
+3.29	Why doesn't lsof find an open socket file whose connection
+	state is past CLOSE_WAIT?
+3.30	Why don't machine.h definitions work when the surrounding
+	comments are removed?
+3.31	What do "can't read inpcb at 0x...", "no protocol control
+	block", "no PCB, CANTSENDMORE, CANTRCVMORE", etc. mean?
+3.32	What do the "unknown file system type" warnings mean?
+3.33	Installation
+3.33.1	How do I install lsof?
+3.33.2	How do I install a common lsof when I have machines that
+	need differently constructed lsof binaries?
+3.34	Why do lsof 4.53 and above reject device cache files built
+	by earlier lsof revisions?
+3.35	What do "like block special" and "like character special" mean
+	in the NAME column?
+3.36	Why does an lsof make fail because of undefined symbols?
+3.37	Command Regular Expressions (REs)
+3.37.1	What are basic and extended regular expressions?
+3.37.2	Why can't I put a slash in a command regular expression?
+3.37.3	Why does lsof say my command regular expression wasn't found?
+3.38	Why doesn't lsof report on shared memory segments?
+3.39	Why does lsof report two instances of itself?
+3.40	Why does lsof report '\n' in device cache file error messages?
+3.41	Kernel Symbol and Address Problems
+3.41.1	What does "lsof: WARNING: name cache hash size length error: 0"
+	mean?
+3.41.2	Why does lsof produce "garbage" output?
+3.42    Why does lsof report open files when run as super user that
+	it doesn't report when run with lesser privileges?
+3.43	Test Suite Problems
+3.43.1	Errors all tests can report:
+3.43.1.1 Why do tests complain "ERROR!!!  can't execute ../lsof"?
+3.43.1.2 Why do tests complain "ERROR!!! can't find ..." a file?
+3.43.1.3 Why do some tests fail to compile?
+3.43.1.4 Why do some tests always fail?
+3.43.1.5 Why does the test suite say it hasn't been validated on
+	 my dialect?
+3.43.1.6 Why do the tests complain they can't stat() or open()
+	 /dev/mem or /dev/kmem?
+3.43.2	LTbigf test issues
+3.43.2.1 Why does the LTbigf test say that the dialect doesn't
+	 support large files?
+3.43.2.2 Why does LTbigf complain about operations on its config.LTbigf*
+	 file?
+3.43.2.3 Why does LTbigf warn that lsof doesn't return file offsets?
+3.43.3	Why does the LTbasic test complain "ERROR!!! lsof this ..."
+	and "ERROR!!!  lsof that ..."?
+3.43.4	LTnfs test issues
+3.43.4.1 Why does the LTnfs test complain "couldn't find NFS file ..."?
+3.43.5	LTnlink test issues
+3.43.5.1 Why does the LTnlink test complain that its test file is on
+	 an NFS file system?
+3.43.5.2 Why does LTnlink delay and report "waiting for link count
+	 update: ..."?
+3.43.5.3 Why does LTnlink fail because of an unlink error?
+3.43.6	LTdnlc test issues
+3.43.6.1 Why won't the LTdnlc test run?
+3.43.6.2 What does the LTdnlc test mean by "... <path> found: 100.00%"?
+3.43.6.3 Why does the DNLC test fail?
+3.43.7	Why hasn't the test suite been qualified for 64 bit HP-UX
+	11 when lsof is compiled with gcc?
+3.43.8	LTszoff test issues
+3.43.8.1 Why does LTszoff warn that lsof doesn't return file offsets?
+3.43.9	LTlock test issues
+3.44	File descriptor list (the ``-d'' option) problems
+3.44.1	Why does lsof reject a ``-d'' FD list?
+3.44.2	Why are file descriptors other than those in my FD list
+	reported?
+3.45	How can I supply device numbers for inaccessible NFS file
+	systems?
+3.46	Why won't lsof find open files on over-mounted file systems?
+3.47	What can be done when lsof reports no more space?
+3.48	What if the lsof build encounters ar and ld problems?
+3.49	Why does lsof -i report an open socket file for a process, but
+	lsof -p on that process' ID report nothing?
+
+4.0	AIX Problems
+4.1	What is the Stale Segment ID bug and why is -X needed?
+4.1.1	Stale Segment ID APAR
+4.2	Gcc Work-around for AIX 4.1x
+4.3	Gcc and AIX 4.2
+4.4	Why won't lsof's Configure allow the use of gcc for AIX
+	below 4.1?
+4.5	What is an AIX SMT file type?
+4.6	Why does AIX lsof start so slowly?
+4.7	Why does exec complain it can't find libc.a[shr.o]?
+4.8	What does lsof mean when it says, "TCP no PCB, CANTSENDMORE,
+	CANTRCVMORE" in a socket file's NAME column?
+4.9	When the -X option is used on AIX 4.3.3, why does lsof disable
+	it, saying "WARNING: user struct mismatch; -X option disabled?"
+4.10	Why doesn't the -X option work on my AIX 5L or 5.[123] system?
+4.11	Why doesn't /usr/bin/oslevel report the correct AIX version?
+4.11.1	Why doesn't /usr/bin/oslevel report the correct AIX version
+	on AIX 5.1?
+4.12    Why does lsof for AIX 5.1 or above Power architecture
+	complain about kernel bit size?
+4.13	What can't gcc be used to compile lsof on the ia64 architecture
+	for AIX 5 and above?
+4.14	Why does lsof get a segmentation fault when compiled with gcc
+	for a 64 bit Power architecture AIX 5.1 kernel?
+4.15	Why does lsof ignore AFS on my AIX system?
+4.16	Why does lsof report "system paging space is low" and exit?
+4.17	Why does lsof have compilation and execution problems on AIX
+	5.3 above maintenance level 1?
+
+5.0	Apple Darwin Problems
+5.1	What do /dev/kmem-based and libproc-based mean?
+5.2	/dev/kmem-based Apple Darwin Questions
+5.2.1	Why does Configure ask for a path to the Darwin XNU kernel
+	header files?
+5.2.1.1	Why does Configure complain that Darwin XNU kernel header
+	files are missing?
+5.2.2	Why doesn't Apple Darwin lsof report text file information?
+5.2.3	Why doesn't Apple Darwin lsof support IPv6?
+5.2.4	Why does lsof complain about a mismatch between the release
+	for which lsof was compiled and the booted Mac OS X release?
+5.2.5	Why does lsof for Apple Darwin 8 and higher report
+	"stat(...): ..." in the NAME column?
+5.2.6	What are the limitations of Apple Darwin lsof link count
+	reporting?
+5.2.7	Why does Apple Darwin report process group IDs incorrectly?"ayy
+5.3	Libproc-based Apple Darwin Questions
+
+6.0	BSD/OS BSDI Problems
+6.0.5	Statement of deprecation
+
+7.0	DEC OSF/1, Digital UNIX, and Tru64 UNIX Problems
+7.1	Why does lsof complain about non-existent /dev/fd entries?
+7.2	Why does the Digital UNIX V3.2 ld complain about Ots* symbols?
+7.3	Why can't lsof locate named pipes (FIFOs) under V3.2?
+7.4	Why does lsof use the wrong configuration header files?
+	For example, why can't the lsof compilation find cpus.h?
+7.5	Why does lsof indicate incomplete paths with " -- " for Tru64
+	UNIX 5.1 files?
+7.6	Why doesn't lsof report link count, node number, and size
+	for some Tru64 5.x CFS files?
+7.7     Why does lsof say it can't read the kernel name list or
+	proc table on Digital UNIX 4.x or Tru64 UNIX?
+
+8.0	FreeBSD Problems
+8.1	Why doesn't lsof report on open kernfs files?
+8.2	Why doesn't lsof work on my FreeBSD system?
+8.3	Why doesn't lsof work on the RELEASE version of CURRENT?
+8.4	Why can't kvm_open() can't find some file?
+8.5	FreeBSD ZFS Problems
+8.5.1	Why does FreeBSD lsof report "WARNING: no ZFS support has been
+8.6	Why can't Configure create lsof_owner.h for FreeBSD 6 and above?
+8.6.1	Why are there lockf structure compiler errors for FreeBSD 6.0
+	and higher lsof?
+8.6.2	Why don't /usr/src/sys/sys/lockf.h and /usr/include/sys/lockf.h
+	match?
+8.7	FreeBSD and clang
+8.7.1	Why does clang complain about VOP_FSYNC?
+
+9.0	HP-UX Problems
+9.1	What do /dev/kmem-based and PSTAT-based mean?
+9.2	/dev/kmem-based HP-UX lsof Questions
+9.2.1	Why doesn't a /dev/kmem-based HP-UX lsof compilation use -O?
+9.2.2	Why doesn't the /dev/kmem-based CCITT support work under 10.x?
+9.2.3	Why can't /dev/kmem-based lsof be compiled with `cc -Aa` or
+	`gcc -ansi` under HP-UX 10.x?
+9.2.4	Why does /dev/kmem-based lsof complain about no C compiler?
+9.2.5	Why does Configure complain about q4 for /dev/kmem-based lsof
+	for HP-UX 11?
+9.2.6	When compiling /dev/kmem-based lsof for HP-UX 11 what do the
+	"aCC runtime: ERROR..." messages mean?
+9.2.7	Why doesn't /dev/kmem-based lsof for HP-UX 11 report VxFS file
+	link counts, node numbers, and sizes correctly?
+9.2.8	Why can't /dev/kmem-based lsof be built with gcc for 64 bit
+	HP-UX 11?
+9.2.8.1	How can I acquire a gcc for building lsof for 64 bit HP-UX 11?
+9.2.9   Why does /dev/kmem-based lsof for HP-UX 11 report "unknown file
+	system type" for VxFS files?
+9.2.10	Why does the ANSI-C compiler complain about comments in HP-UX
+	11 header files?
+9.2.11  Why does dnode1.c cause the HP-UX 11 compiler to complain that
+	<sys/fs/vx_inode.h> is missing or incorrect?
+9.3	PSTAT-based HP-UX lsof Questions
+9.3.1	Why does PSTAT-based lsof complain about pst_static and
+	other PSTAT structures?
+9.3.2	Why does PSTAT-based lsof complain it can't read pst_*
+	structures?
+9.3.3	Why does PSTAT-based lsof rebuild the device cache file
+	after each reboot?
+9.3.4	Why doesn't PSTAT-based lsof report TCP addresses for
+	telnetd's open socket files?
+9.3.5   Why does PSTAT-based lsof cause an HP-UX 11.11 kernel panic?
+9.3.6   Why doesn't PSTAT-based lsof report a CWD that is on a loopback
+	(LOFS) file system?
+9.3.7	Why do some swinstall packages for PSTAT-based HP-UX 11.11
+	packages complain about setgid and setuid bits?
+9.3.8	Why won't the bundled C compiler build PSTAT-based lsof for
+	PA-RISC HP-UX 11.23?
+9.3.9	Why won't gcc build PSTAT-based lsof for PA-RISC HP-UX 11.23?
+9.3.10	Why does PSTAT-based lsof complain, "FATAL: pst_stream_size
+	should be: 672; is 72" on HP-UX 11.11 and above?
+9.4	Why won't the HP-UX depot install?
+
+10.0	Linux Problems
+10.1	What do /dev/kmem-based and /proc-based lsof mean?
+10.2	/proc-based Linux lsof Questions
+10.2.1	Why doesn't /proc-based lsof report file offsets (positions)?
+10.2.2	Why does /proc-based lsof report "can't identify protocol" for
+	some socket files?
+10.2.3	Why does /proc-based lsof warn about unsupported formats?
+10.2.4	Why does /proc-based lsof report "(deleted)" after a path name?
+10.2.5	Why doesn't /proc-based lsof report full open file information
+	for all processes?
+10.2.6	Why won't Customize offer to change HASDCACHE or WARNDEVACCESS
+	for /proc-based lsof?
+10.2.7	/proc-based lsof Linux NFS questions
+10.2.7.1 Why can't lsof find files on an accessible NFS file system?
+10.2.7.2 Why can't lsof find files on an inaccessible NFS file system?
+10.2.8	Why doesn't /proc-based Linux lsof report socket options and
+	values, socket state flags, and TCP options and values?
+10.2.9	Does /proc-based Linux lsof use a device cache?
+10.2.10	Why doesn't /proc-based Linux lsof report any or all file structure
+	values for its +fcfgGn option?
+10.3	Special Linux file types
+10.3.1	Why is ``DEL'' reported as a Linux file type?
+10.3.2	Why is ``unknown'' reported as a Linux file type?
+10.4	Linux ``mem'' Entry Problems
+10.4.1  What do ``path dev=xxx'' and ``path inode=yyy'' mean in the
+	NAME column of Linux ``mem'' file types?
+10.4.2  Why is neither link count nor size reported for some Linux
+	``DEL'' and ``mem'' file types?
+10.5	Special Linux NAME column messages
+10.5.1  What does ``(stat: xxx)'' mean in the NAME column of Linux
+	files?
+10.5.2  What does ``(readlink: xxx)'' mean in the NAME column of
+	Linux files?
+10.6	Why is ``NOFD'' reported as a Linux file type?
+10.7    Why does Linux lsof report a NAME column value that begins with
+	``/proc''?
+10.8	Linux /proc/net/tcp* and /proc/net/udp* issues
+10.8.1	Why use the Linux -X option?
+10.8.2	Why does lsof say ``-i is useless when -X is specified''?
+10.8.3	Why does lsof say ``can't identify protocol (-X specified)''?
+
+11.0	NetBSD Problems
+11.1	Why doesn't lsof report on open kernfs files?
+11.2	Why doesn't lsof report on open files on: file descriptor
+	file systems; /proc file systems; 9660 (CD-ROM) file systems;
+	MS-DOS (floppy disk) file systems; or kernel file systems?
+11.3    Why does lsof produce confusing results for nullfs file
+	systems?
+11.4	NetBSD header file problems
+11.4.1	Why can't the compiler find some NetBSD header files?
+11.4.2	Why does NetBSD lsof produce incorrect output?
+11.5	Why isn't lsof feature xxx enabled for NetBSD?
+
+12.0	NEXTSTEP and OPENSTEP Problems
+12.1	Why can't lsof report on 3.1 lockf() or fcntl(F_SETLK)
+	locks?
+12.2	Why doesn't lsof compile for NEXTSTEP with AFS?
+
+13.0	OpenBSD Problems
+13.1	Why doesn't lsof support kernfs on my OpenBSD system?
+13.2	Will lsof work on OpenBSD on non-x86-based architectures?
+13.3	<sys/pipe.h> problems
+13.3.1	Why does the compiler claim nbpg isn't defined?
+13.3.2	What value should I assign to nbpg?
+13.4	Why doesn't lsof report on open MS-DOS file system (floppy
+	disk) files?
+13.5	Why isn't lsof feature xxx enabled for OpenBSD?
+
+14.0	Output problems
+14.1	Why do the lsof column sizes change?
+14.2	Why does the offset have ``0t' and ``0x'' prefixes?
+14.3	What are the values printed in the FILE_FLAG column
+	and why is 0x<value> sometimes included?
+14.3.1	Why doesn't lsof display FILE_FLAG values for my dialect?
+14.4	Network Addresses
+14.4.1	Why does lsof's -n option cause IPv4 addresses, mapped to
+	IPv6, to be displayed in IPv6 notation?
+14.5	Why does lsof output \x, ^x, or \xnn for characters
+	sometimes?
+14.5.1  Why is space considered a non-printable character in command
+	names?
+14.6	Why doesn't lsof print all the characters of a command name?
+14.7	Why does lsof reject some -c command names, saying their lengths
+	are "> what system provides (nn)"?
+14.8	Why does lsof sometimes print TYPE numbers instead of names?
+14.9	Marker line format problems
+14.9.1	Why won't lsof accept a marker line format?
+14.9.2	Why does lsof reject the NL (%n) marker line format?
+14.10	How are protocol state name exclusion and inclusion used?
+14.10.1	Why doesn't my dialect support state name exclusion and inclusion?
+
+15.0	Pyramid Version Problems
+15.0.5	Statement of deprecation
+
+16.0	SCO Problems
+16.1	SCO OpenServer Problems
+16.1.1	How can I avoid segmentation faults when compiling lsof?
+16.1.2	Where is libsocket.a?
+16.1.3	Why do I get "warning C4200" messages when I compile lsof?
+16.2	SCO|Caldera UnixWare Problems
+16.2.1  Why doesn't lsof compile on my UnixWare 7.1.1 or above
+	system?
+16.2.2	Why does lsof complain about node_self() on my UnixWare
+	7.1.1 or above system?
+16.2.3  Why does UnixWare 7.1.1 or above complain about -lcluster,
+	node_self(), or libcluster.so?
+16.2.4  Why does UnixWare 7.1.1 or above lsof complain it can't
+	read the kernel name list?
+16.2.5  Why doesn't lsof report link count, node number, and size
+	for some UnixWare 7.1.1 or above CFS files?
+16.2.6  Why doesn't lsof report open files on all UnixWare 7.1.1
+	NonStop Cluster (NSC) nodes?
+16.2.7	Why doesn't lsof report the UnixWare 7.1.1 NonStop Cluster
+	(NSC) node a process is using?
+16.2.8  Why does the compiler complain about missing UnixWare 2.1[.x]
+	header files?
+
+17.0	Sun Problems
+17.0.5	Statement of deprecation
+17.1	My Sun gcc-compiled lsof doesn't work -- why?
+17.2	How can I make lsof compile with gcc under Solaris 2.[456],
+	2.5.1, 7, 8 or 9?
+17.3	Why does Solaris Sun C complain about system header files?
+17.4	Why doesn't lsof work under my Solaris 2.4 system?
+17.5	Where are the Solaris header files?
+17.6	Where is the Solaris /usr/src/uts/<architecture>/sys/machparam.h?
+17.7	Why does Solaris lsof say ``can't read proc table''?
+17.8	Why does Solaris lsof complain about a bad cached clone device?
+17.9	Why doesn't Solaris make generate .o files?
+17.10	Why does lsof report some Solaris 2.3 and 2.4 lock types as `N'?
+17.11	Why does lsof Configure say "WARNING: no cc in ..."?
+17.12	Solaris 7, 8 and 9 Problems
+17.12.1	Why does lsof say the compiler isn't adequate for Solaris
+	7, 8 or 9?
+17.12.2 Why does Solaris 7, 8 or 9 lsof say "FATAL: lsof was compiled
+	for..."?
+17.12.3	How do I build lsof for a 64 bit Solaris kernel under a 32
+	bit Solaris kernel?
+17.12.4	How do I install lsof for Solaris 7, 8 or 9?
+17.12.5 Why does my Solaris 7, 8 or 9 system say it cannot execute
+	lsof?
+17.12.6 What gcc will produce 64 bit Solaris 7, 8 and 9 executables?
+17.12.7 Why does lsof on my Solaris 7, 8 or 9 system say, "can't
+	read namelist from /dev/ksyms?"
+17.13	Solaris and COMMON
+17.13.1	What does COMMON mean in the NAME column for a Solaris VCHR
+	file?
+17.13.2	Why does a COMMON Solaris VCHR file sometimes seem to have an
+	incorrect minor device number?
+17.14	Why don't lsof and Solaris pfiles reports always match?
+17.15	Why does lsof say, "kvm_open(namelist=default, core=default):
+	Permission denied?"
+17.16	Why is lsof slow on my busy Solaris UFS file system?
+17.17	Why is lsof so slow on my Solaris 8 or 9 system?
+17.18	Solaris and VxFS
+17.18.1	Why doesn't lsof support VxFS 3.4 on Solaris 2.6, and above?
+17.18.2	Why does lsof report "vx_inode: vxfsu_get_ioffsets error"
+	for open Solaris 2.6 and above VxFS 3.4 and above files?
+17.18.3	Why does Solaris Configure claim there is no VxFS library?
+17.18.4	Why doesn't Solaris lsof report VxFS path name components?
+17.18.5	Why does Solaris 10 lsof report scrambled VxFS paths?
+17.19	Large file problems
+17.19.1	Why does lsof complain it can't stat(2) a Solaris 2.5.1
+	large file?
+17.20   Why does lsof get a segmentation fault on 64 bit Solaris
+	8 using NIS+?
+17.21	Will lsof crash the Solaris kernel?
+17.22   Why does lsof on Solaris 7, 8, or 9 report a kvm_open()
+	failure?
+17.23	Solaris and SAM-FS
+17.23.1	Why does Solaris lsof report "(limited SAM-FS info)"?
+17.23.2	Why can't lsof locate named SAM-FS files?
+17.24	Lsof and Solaris 10 zones
+17.24.1	How can I make lsof list the Solaris zone?
+17.24.2	Why doesn't lsof work in a Solaris 10 zone?
+17.24.3 Why does lsof complain it can't stat() Solaris 10 zone file
+	systems?
+17.25	Solaris 10 problems
+17.25.1 Why does Solaris 10 lsof sometimes report the wrong path name?
+17.25.2 Why does Solaris 10 lsof sometimes report only the mounted-on
+	directory and device?
+17.25.3 What does "(deleted)" mean in the NAME column of a Solaris 10
+	open file?
+17.25.4 What does "(?)" mean in the NAME column of a Solaris 10 open
+	file?
+17.26	Solaris contract file problems
+17.26.1	Why doesn't lsof report size, link count and node number for
+	Solaris 10 contract files?
+17.26.2 Why can't lsof locate a Solaris 10 contract file by path name?
+17.27	Solaris 10 and above ZFS probblems
+17.27.1	Why does Configure warn that ZFS support is not enabled?
+17.28	Problems with Solaris 9 and above
+17.28.1	Why does the compiler complain about lgrp_root on Solaris 9
+	and above?
+
+18.0	Lsof Features
+18.1	Why doesn't lsof doesn't report on /proc entries on my
+	system?
+18.2	How do I disable the device cache file feature or alter
+	it's behavior?
+18.2.1	What's the risk with a perverted device cache file?
+18.2.2	How do I put the full host name in a personal device cache file
+	path?
+18.2.3	How do I put the personal device cache file in /tmp?
+18.3	Why doesn't lsof know about AFS files on my favorite dialect?
+18.3.1	Why doesn't lsof report node numbers for all AFS volume files,
+	or how do I reveal dynamic module addresses to lsof?
+______________________________________________________________________
+
+
+1.0	General Concepts
+
+1.1	Lsof -- what is it?
+
+	Lsof is a UNIX-specific tool.  Its name stands for LiSt
+	Open Files, and it does just that.  It lists information
+	about files that are open by the processes running on a
+	UNIX system.
+
+	See the lsof man page, the 00DIST file, the 00QUICKSTART
+	file, and the 00README file of the lsof distribution for
+	more information.
+
+1.2	Where do I get lsof?
+
+	Lsof is available via anonymous ftp from lsof.itap.purdue.edu.
+	Look in the pub/tools/unix/lsof sub-directory.
+
+	    ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof
+
+	Bzip2'd, compressed and gzip'd tar files with GPG certificates
+	are available.
+
+1.2.1	Are there mirror sites?
+
+	On April 28, 2009 these sites appeared to have the lastest
+	lsof revision:
+
+	ftp://ftp.fu-berlin.de/pub/unix/tools/lsof
+	ftp://sunsite.ualberta.ca/pub/Mirror/lsof
+
+1.2.2	Are lsof executables available?
+
+	Some lsof executables are available in the subdirectory
+	tree pub/tools/unix/lsof/binaries  These are neither guaranteed
+	to be current nor cover every dialect and machine architecture.
+
+	I don't recommend you use pre-compiled lsof binaries; I
+	recommend you obtain the sources and build your own binary.
+	Even if you're a Sun user without a Sun C compiler, you
+	can use gcc to compile lsof.
+
+	If you must use a binary file, please be conscious of the
+	security and configuration implications in using an executable
+	of unknown or different origin.  The lsof binaries are
+	accompanied by GPG certificates.  Please use them!
+
+	Three additional cautions apply to executables:
+
+	1.  Don't try to use an lsof executable, compiled for one
+	    version of a UNIX dialect, on another.  Patches can
+	    make the dialect version different.
+
+	2.  If you want to use an lsof binary on multiple systems,
+	    they must be running the same dialect OS version and
+	    have the same patches and feature support.
+
+1.2.3	How do I check the validity of an lsof distribution?
+
+	There are two ways to check the validity of an lsof
+	distribution:
+
+	1.  Follow the instructions in the CHECKSUMS_<revision>
+	    file found with the lsof distribution.
+
+	    Checking with GPG is the best method.
+
+	2.  Follow the instructions in the "Security" section of the
+	    README.lsof_<revision> file found inside the lsof
+	    distribution.
+
+	    Again, checking with GPG is the best method.
+
+1.2.4	Why can't I get the sum(1) result reported in
+	README.lsof_<revision>?
+
+	The "Security" section of the README.lsof_<revision> file found
+	inside the lsof distribution gives md5, sum, and GPG certificate
+	information.
+
+	The simplest, the sum(1) signature, seems to be the trickiest.
+	That's because there are different sum(1) methods, BSD systems
+	usually have cksum(1) instead of sum(1), and different systems
+	compute the block size value differently.
+
+	First, the lsof sum results are computed with the old,
+	"alternate" algorithm.  On newer systems, you can use sum's
+	"-r" option to get that computation result.
+
+	Second, on BSD systems you usually must use cksum(1) instead
+	of sum(1), because they have no sum(1).  To tell cksum(1)
+	to use the old, "alternate" algorithm, use its "-o1" option.
+
+	Third, the second value that sum reports, the block count, may
+	be computed differently on different systems -- usually block
+	size is considered to be 512 or 1,024.  The lsof block counts
+	were computed on a system with a sum(1) option that considers
+	block size to be 512.  The BSD system cksum(1) -o1 option
+	considers block size to be 1,024.  If your sum(1) or cksum(1)
+	doesn't report a block count that matches the sum(1) signature
+	given in README.lsof_<revision>, check its man page to see what
+	block size it uses, then adjust its reported block count
+	appropriately.
+
+1.2.5	Why won't gpg accept the lsof-signing PGP public key?
+
+	An older PGP key that once signed lsof distributions is
+	included in lsof revisions prior to 4.70.  The PGP key is
+	indeed my key, but is incompatible with GPG.  It was created
+	about ten years ago and is still acceptable to PGP versions
+	2.6.2 through 6.5.2.
+
+	Lsof revisions 4.70 and above are signed with a copy of my PGP
+	key that has been made acceptable for use with GPG by importing
+	it under GPG's "--allow-non-selfsigned-uid" option.
+
+	You can find my GPG compatible key in lsof revisions 4.70 and
+	above and at:
+
+	    ftp://lsof.itap.purdue.edu/pub/Victor_A_Abell.gpg
+
+	If you have an older lsof revision with my PGP key, there are
+	two possible ways to use it:
+
+	* Use it with a PGP version from 2.6.2 through 6.5.2.
+
+	* Use GPG's "--allow-non-selfsigned-uid" option when you
+	  import my PGP key into your GPG key ring.
+
+	  $ gpg --allow-non-selfsigned-uid --import Victor_A_Abell.pgp
+
+1.3	Where can I get more lsof documentation?
+
+	A significant set of documentation may be found in the lsof
+	distribution (See "Where can I get lsof?).  There is a
+	manual page, copious documentation in files whose names
+	begin with 00, and a copy of this FAQ in the file 00FAQ
+	(perhaps slightly less recent than this file if you're
+	reading it via a web browser.)
+
+	Two URLs provide some documentation that appears in the
+	lsof distribution:
+
+	FAQ: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ
+
+	man page: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_man
+
+1.4	How do I report an lsof bug?
+
+	If you believe you have discovered a bug in lsof, you can
+	report it via e-mail to <abe@purdue.edu>.  Do NOT report lsof
+	bugs to the UNIX dialect vendor. Make sure "lsof" appears in
+	the "Subject:" line so my e-mail filter won't classify your
+	letter as Spam.
+
+	Before you send me a bug report, please read the "Bug Reports"
+	section of the 00README file of the lsof distribution.  It
+	lists the steps you should take before and when reporting a
+	suspected bug.
+
+1.5	Where can I get the lsof FAQ?
+
+	This lsof FAQ is available in the file 00FAQ in the lsof
+	distribution and at the URL:
+
+	    ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ
+
+1.5.1	How timely is the on-line FAQ?
+
+	The on-line FAQ is sometimes too timely.  :-)
+
+	I update it as soon as new information is available.   That may
+	include information about support that won't appear in the lsof
+	source distribution until the next revision.  If you encounter
+	something like that, please send me e-mail at <abe@purdue.edu>.  I
+	may be able to point you at a pre-release distribution that contains
+	the support of interest.  Make sure "lsof" appears in the "Subject:"
+	line so my e-mail filter won't classify your letter as Spam.
+
+1.6	Is there a test suite?
+
+	Yes, as of lsof revision 4.63 there's an automated lsof
+	test suite in the tests/ sub-directory of the lsof top-level
+	directory.
+
+	More information on using the test suite, what it does,
+	how to use it and how to configure it may be found in the
+	00TEST file of the lsof distribution.  That file also
+	explains where the test suite has been tested.
+
+	Frequently asked questions about the test suite will be
+	asked and answered here in the FAQ.  (See "Test Suite
+	Problems.")
+
+	After lsof has been configured with the Configure script,
+	lsof can be made and tested with:
+
+	    $ make
+	    $ cd tests
+	    $ make
+
+	Under normal conditions -- i.e., unless the lsof tree has
+	been cleaned or purged severely -- all tests or individual
+	tests may be run by:
+
+	    $ cd test
+	    $ make
+	 or
+	    $ <run a single test>	(See 00TEST.)
+
+1.7	Is lsof vulnerable to the standard I/O descriptor attack?
+
+	Lsof revisions 4.63 and above are not vulnerable.
+
+	Lsof revisions 4.62 and below are vulnerable, but no damage
+	scenarios have so far been demonstrated.
+
+	The standard I/O descriptor attack is a local programmed
+	assault on setuid and setgid programs that tricks them into
+	opening a sensitive file with write access on a standard
+	descriptor, usually stderr (2), and writing error messages
+	to stderr.  If the attacker can control the content of the
+	error message, the attacker may gain elevated privileges.
+
+	The attack was first described in Pine Internet Advisory
+	PINE-CERT-20020401, available at:
+
+	    http://www.pine.nl/advisories/pine-cert-20020401.txt
+
+	If you are using an lsof revision below 4.63, you should
+	remove any setuid or setgid permissions you might have
+	given its executable.  Then you should upgrade to lsof
+	revision 4.63.
+
+1.8	Can I alter lsof's make(1) behavior?
+
+	Yes.  There are at least two ways to do that.
+
+	You can put replacements for lsof Makefile strings in your
+	environment.  If you specify the -e make option, make will
+	give environment variable values precedence over strings
+	from the Makefile.  For example, to change the compiler
+	string CC from the environment, you might do this with the
+	Bourne shell:
+
+	    $ CC=foobar; export CC
+	    $ make -e
+
+	You can also replace lsof Makefile strings in the make
+	command invocation.  Here's the previous example done that
+	way:
+
+	    $ make CC=foobar
+
+	Changing the CFGF, CFGL, and DEBUG strings used in lsof
+	Makefiles, either from the environment or from the make
+	invocation, can significantly alter lsof make(1) behavior.
+	I commonly use DEBUG to change the -O option to -g so I
+	can build an lsof executable for debugging -- e.g.,
+
+	    $ make DEBUG=-g
+	
+	(Look for DEBUG in this FAQ for other examples of its use.)
+
+	Consult the Makefiles to see what CFGL, CFGL, and other
+	lsof Makefile strings contain, and to see what influence
+	their alteration might have on lsof make(1) behavior.
+
+1.9	Is there an lsof license?
+
+	No.
+
+	The only restriction on the use or redistribution of lsof
+	is contained in this copyright statement, found in every
+	lsof source file.  (The copyright year in or format of the
+	notice may vary slightly.)
+
+	/*
+	 * Copyright 2002 Purdue Research Foundation, West Lafayette,
+	 * Indiana 47907.  All rights reserved.
+	 *
+	 * Written by Victor A. Abell
+	 *
+	 * This software is not subject to any license of the American
+	 * Telephone and Telegraph Company or the Regents of the
+	 * University of California.
+	 *
+	 * Permission is granted to anyone to use this software for
+	 * any purpose on any computer system, and to alter it and
+	 * redistribute it freely, subject to the following
+	 * restrictions:
+	 *
+	 * 1. Neither the authors nor Purdue University are responsible
+	 *    for any consequences of the use of this software.
+	 *
+	 * 2. The origin of this software must not be misrepresented,
+	 *    either by explicit claim or by omission.  Credit to the
+	 *    authors and Purdue University must appear in documentation
+	 *    and sources.
+	 *
+	 * 3. Altered versions must be plainly marked as such, and must
+	 *    not be misrepresented as being the original software.
+	 *
+	 * 4. This notice may not be removed or altered.
+	 */
+
+1.10	Language locale support
+
+1.10.1	Does lsof support language locales?  How do I use the support?
+
+	Most UNIX dialect versions of lsof support 8 bit language
+	locale characters -- e.g., the ability to print 8 bit
+	characters that have accents and other marks over them.
+	
+	See the answer to the "Does lsof support wide characters in
+	language locales?" question for information on when lsof's
+	language locale support covers characters wider than 8 bits.
+
+	To see if lsof supports language locales for your dialect, look
+	in the dialect's machine.h header file for the HASSETLOCALE
+	definition.  If it is present and not disabled, then lsof has
+	language locale support for the dialect.
+
+	To enable lsof's language locale support, you must specify in a
+	locale environment variable (e.g., LANG) a language locale
+	known to your system that supports the printing of marked
+	characters -- e.g, en_US.  (On some dialects locale(1) may be
+	used to list the known language locales.)
+
+	Note that LANG=C and LANG=POSIX are NOT language locales that
+	support the printing of marked characters.
+
+	If the language locale doesn't support the printing of marked
+	characters, lsof's OUTPUT of them follows the rules for
+	non-printable characters described in the OUTPUT section of
+	lsof(8).
+
+	Consult your dialect's setlocale(3) man page for the names of
+	environment variables other than LANG  -- e.g., LC_ALL,
+	LC_TYPE, etc. -- which may be used to define language locales.
+
+1.10.2	Does lsof support wide characters in language locales?
+
+	When lsof's language locale support is enabled with the
+	HASSETLOCALE definition, for selected dialects lsof will also
+	print wide characters (e.g., from UTF-8) when iswprint(3)
+	reports them to be printable.
+
+	Wide character support is available when HASWIDECHAR is defined
+	in a dialect's machine.h header file.  As of this writing on
+	July 22, 2004, the following dialect versions have wide character
+	support:
+
+	    AIX >= 4.3.2
+	    Apple Darwin >= 7.3.0
+	    FreeBSD >= 5.2
+	    HP-UX >= 11.00
+	    /proc-based Linux
+	    NetBSD >= 1.6
+	    SCO OpenServer >= 5.0.6
+	    Solaris >= 2.6
+	    Tru64 UNIX 5.1
+
+1.11	Are any files in the lsof distribution copyrighted?
+
+	Yes.  Most files carry the copyright of the Purdue Research
+	Foundation and may be redistributed under the terms that
+	accompany the copyright notice.  Those terms may also be found
+	in the answer to the question, "Is there an lsof license?")
+
+	A few files carry other copyright notices.  Some are BSD
+	notices and they explain the terms under which they are
+	included in the lsof distribution.
+	
+	Those that carry vendor copyright notices have been reproduced
+	in their original or modified forms with permission from the
+	copyright owners.  That permission is indicated in the README
+	files that accompany the files.
+
+1.12	Are there other lsof-related resources?
+
+	There are other resources available, connected to lsof.  Among
+	them are FreeBSD and Linux packages whose products use lsof and
+	two particularly interesting resources.
+
+	The two interesting resources are a Gnome Tool Kit (GTK) GUI
+	for lsof and a Perl wrapper module.
+
+	The GTK GUI is called Glsof and was developed by Gnele.  It can
+	be found at:
+
+	    http://www.sourceforge.net
+
+	The Perl wrapper module by Marc Beyer can be found at:
+
+	    http://search.cpan.org/dist/Unix-Lsof/
+
+1.13	What does the "WARNING: unsupported dialect or version" mean?
+
+	The lsof configure script issues that message for UNIX dialects
+	or their versions where I have been unable to test the current
+	revision of lsof.  The message doesn't mean that lsof won't
+	work, just that I have no direct evidence that it will.
+
+	If the COnfigure script succeeds, except for the warning, try
+	compiling) lsof.  If that succeeds, try the lsof test suite.
+
+2.0	Lsof Ports
+
+2.1	What ports exist?
+
+	The pub/lsof.README file carries the latest port information:
+
+	    AIX 5.[23] and 5.3
+	    FreeBSD 4.9 and 6.4 for x86-based systems
+	    FreeBSD 8.2, 9.0 and 10.0 for AMD64-based systems
+	    Linux 2.1.72 and above for x86-based systems
+	    Solaris 9, 10 and 11
+
+	In the above list the only UNIX dialects present are ones for
+	which I test the current lsof revision.  Lsof may still support
+	unlisted dialect versions -- e.g., HP-UX 10.20, Solaris 7, etc.
+	-- but I don't have access to systems where I could test lsof
+	on them, so I can't claim lsof works on them. If your dialect
+	isn't in the list, you should try building lsof on it anyway.
+
+	Lsof version 4 predecessors, versions 2 and 3, may support older
+	version of some dialects.  Contact me via e-mail at <abe@purdue.edu>
+	if you're interested in their distributions.  Make sure "lsof"
+	appears in the "Subject:" line so my e-mail filter won't classify
+	your letter as Spam.
+
+2.2	What about a new port?
+
+	The 00PORTING file in the distribution gives hints on doing
+	a port.  I will consider doing a port in exchange for
+	permanent access to a test host.  I require permanent access
+	so I can test new lsof revisions, because I will not offer
+	distributions of dialect ports I cannot upgrade and test.
+
+2.2.1	User-contributed Ports
+
+	Sometimes I receive contributions of ports of lsof to
+	systems where I can't test future revisions of lsof.  Hence,
+	I don't incorporate these contributions into my lsof
+	distribution.
+
+	However, I do make descriptions of these contributions
+	available.  You can find them in the 00INDEX and README
+	files at:
+
+	    ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/contrib
+
+	Consult the 00INDEX file in the contrib/ directory for a
+	list of the available contributions and consult README
+	there for information on how to obtain them.
+
+2.3	Why isn't there an AT&T SVR4 port?
+
+	I haven't produced an AT&T SVR4 port because I haven't seen
+	a UNIX dialect that is strictly limited to the AT&T System
+	V, Release 4 source code.  Every one I have seen is a
+	derivative with vendor additions.
+
+	The vendor additions are significant to lsof because they
+	affect the internal kernel structures with which lsof does
+	business.  While some vendor derivatives of SVR4 are similar,
+	each one I have encounted so far has been different enough
+	from its siblings to require special source code.
+
+	If you're interested in an SVR4 version of lsof, here are
+	some existing ports you might consider:
+
+	    DC/OSx (This obsolete port is only available upon
+		    special request.)
+	    Reliant UNIX (This obsolete port is only available
+			  upon special request.)
+	    SCO|Caldera UnixWare (This is the most likely choice.)
+	    Solaris
+
+2.4	Why isn't there an SGI IRIX port?
+
+	Lsof support for IRIX was terminated at lsof revision 4.36,
+	because it had become increasingly difficult for me to
+	obtain information on the IRIX kernel structures lsof needs
+	to access.
+
+	At IRIX 6.5 I decided the obstacles were too large for me
+	to overcome, and I stopped supporting lsof on IRIX.  I have
+	sources to the last revision of lsof (4.36) for IRIX, but
+	that version of lsof does not work on IRIX 6.5 and is
+	vulnerable to the standard I/O descriptor attack.  (See
+	the "Is lsof vulnerable to the standard I/O descriptor
+	attack?" Q&A for more information.) Contact me to discuss
+	obtaining those sources.
+
+	If you wish to pursue the issue, don't contact me, contact
+	SGI.  This case was opened with SGI on the subject:
+
+	    Case ID:	0982584
+	    Category: Unix
+	    Priority: 30-Moderate Impact
+
+	    Problem Summary:
+	    kernel structure header files needed for continued lsof
+	    support
+
+	    Problem Description:
+	    Email In  07/17/98 19:09:23
+
+2.5	Why does lsof's Configure script report "WARNING: unsupported
+	dialect or version"?
+
+	Lsof's Configure script issues this message when it encounters
+	a dialect or its version that lsof once supported, but no
+	longer does.  Usually I drop support for a dialect or version
+	when I can no longer test lsof on it.
+
+	However, it's worth trying to compile and use lsof.  Be sure to
+	run the test suite.  (See the answer to the "Is there a test
+	suite?  question for information on the test suite.)
+
+	If you have problems with an unsupported dialect or version,
+	contact me via e-mail at <abe@purdue.edu> and I may be able to help.
+	Make sure "lsof" appears in the "Subject:" line so my e-mail filter
+	won't classify your letter as Spam.
+
+
+3.0	Lsof Problems
+
+3.1	Configuration Problems
+
+3.1.1	Why can't Configure determine the UNIX dialect version?
+
+	The lsof Configure script uses UNIX shell commands, often in a
+	command pipeline, to determine the UNIX dialect version.
+	(Consult the dialect stanza in Configure to determine which
+	commands are used.)  If Configure can't determine the dialect
+	version, probably one of the commands is not behaving as
+	Configure expects.
+
+	Symptoms of the failure include Configure warning messages and
+	incorrect version definitions in the Makefile CFLAGS.
+
+	If you suspect that the lsof Configure script is failing to
+	determine the dialect version correctly, try running the
+	commands from Configure stanza one at a time.  That will
+	usually reveal the source of the problem.  Be particularly
+	mindful that the PATH environment variable can cause commands
+	to be executed from non-standard directories.
+
+	If you can't determine the source of the problem, there is a
+	work-around.  You can supply the UNIX dialect version in the
+	LSOF_VSTR environment variable.  Use Configure as a guide to
+	forming what it expects in LSOF_VSTR.  There is also some
+	information on  LSOF_VSTR in the 00XCONFIG documentation file
+	of the lsof distribution.
+
+3.2	Compilation Problems
+
+3.2.1	Why does the compiler complain about missing header files?
+
+	When you use make to build lsof, the compiler may complain
+	that it can't find header files -- e.g.,
+
+	    $ make
+	    (cd lib; make DEBUG="-O" CFGF="-DAIXA=0 -DAIXV=4330 \
+	    -DLSOF_VSTR=\"4.3.3.0\"")
+	    gcc  -DAIXA=0 -DAIXV=4330 -DLSOF_VSTR="4.3.3.0" -O \
+	    -c ckkv.c
+	    In file included from ckkv.c:33: ../machine.h:70: \
+	    sys/types.h: A file or directory in the path name \
+	    does not exist. \
+
+       That type of complaint doesn't represent an lsof problem.
+       It represents a problem with a missing system header file
+       that probably should be found in /usr/include or in the
+       system source tree.
+
+       As a first step try using find(1) to locate the problem
+       header file.  If it's a system header file and can't be
+       found, here are some possible causes:
+
+	1. The file set, RPM or package containing the header files
+	   has not been installed.  Instructions for doing that
+	   are specific to the UNIX dialect and beyond the scope
+	   of this document.
+
+	2. If the compiler is gcc, the private gcc header files:
+
+	   * May not have been installed;
+	   
+	   * May have been installed incorrectly;
+	   
+	   * May not have been updated properly after the last
+	     compiler or system update;
+	     
+	   * Ones from a previous installation may not have been
+	     removed.
+	     
+	   A path leading to the gcc private header files can be
+	   found with `gcc -v`.  Consult the gcc documentation for
+	   instructions on proper installation of the private gcc
+	   header files.
+
+	3. On some dialects -- e.g., FreeBSD, NetBSD, OpenBSD --
+	   lsof may need to use header files that are located in
+	   the system source tree -- /sys or /usr/src/sys, for
+	   example.  Make sure the system source tree has been
+	   installed.
+
+3.2.2   Why does gcc complain about the contents of header files
+	distributed by the system's vendor?
+
+	When you use make to build lsof and gcc to compile it, gcc
+	may complain that it finds errors in system header files
+	-- e.g.,
+
+	    $ make
+	    (cd lib; make DEBUG="-O" CFGF="-Dsolaris=80000 \
+	     -DHASPR_GWINDOWS -m64 -DHASIPv6 -DHAS_VSOCK \
+	     -DLSOF_VSTR=\"5.8\"")
+	     gcc -Dsolaris=80000  -DHASPR_GWINDOWS -m64 -DHASIPv6 \
+	     -DHAS_VSOCK -DLSOF_VSTR="5.8"  -O  -c  dvch.c
+	    In file included from /usr/include/sys/proc.h:31, \
+             from /homes/abe/gnu/gcc-3.2.1/lib/gcc-lib/sparcv9-sun-solaris2/ \
+	     3.2.1/include/sys/user.h:267, from /usr/include/kvm.h:13, \
+	     from ../dlsof.h:53, from ../lsof.h:172, from dvch.c:43: \
+	     /homes/abe/gnu/gcc-3.2.1/lib/gcc-lib/sparcv9-sun-solaris2/\
+	      3.2.1/include/sys/task.h:59: parse error before "uint_t"
+
+	Errors like the above are most likely not problems in the
+	system's header files, but in the private copies of them
+	that were created when gcc was made or installed.  Note
+	the presense of
+	".../gcc-3.2.1/lib/gcc-lib/sparcv9-sun-solaris2/3.2.1/include/..."
+	in the paths for user.h and task.h.  It indicates both
+	header files are gcc-specific.
+
+	To solve errors like this requires comparing the header
+	files in the vendor's /usr/include tree to the gcc-specific
+	ones in gcc's private gcc-lib/.../include tree.  It may be
+	necessary to regenerate gcc-specific header files, correct
+	them or remove them.  See the gcc distribution for the
+	appropriate tools.
+
+	A possible temporary work-around is to direct gcc to use
+	the vendor's header files instead of its temporary ones by
+	declaring -I/usr/include in the compilation flags.
+
+3.2.3	Other header file problems
+
+	Don't overlook any vendor tools that might validate the
+	vendor header files installed on the system  -- e.g., the
+	Solaris pkgchk tool can be used to check the header files
+	that were installed from the SUNWhea package.
+
+	For other header file problems contact me at <abe@purdue.edu>.
+	Please follow the reporting guidelines in the "How do I
+	report an lsof bug?" section of this FAQ.
+
+3.3	Why doesn't lsof report full path names?
+
+	Lsof reports the full path name when it is specified as a
+	search argument for open files that match the argument.
+	However, if the argument is a file system mounted-on
+	directory, and lsof finds additional path name components
+	from the kernel name cache, it will report them.
+
+	Lsof reports path name for file system types that have path
+	name lookup features -- e.g., some versions of AdvFS for
+	Digital and Tru64 UNIX.  The Linux /proc-based lsof reports
+	full path names, because the Linux /proc file system provides
+	them.  Lsof on recent builds of Solaris 10 also report full
+	path names, because those Solaris kernels record the full path
+	name in the vnode structure.
+
+	Otherwise, lsof uses the kernel name cache, where it exists
+	and can be accessed, and reports some or all path name
+	components (e.g., the sys and proc.h components of
+	/usr/include/sys/proc.h) for these dialects:
+
+		Apple Darwin
+		DC/OSx
+		FreeBSD
+		HP-UX, /dev/kmem and PSTAT based
+		Linux, /dev/kmem-based
+		NetBSD
+		NEXTSTEP
+		OpenBSD
+		OPENSTEP
+		Reliant UNIX
+		SCO OpenServer
+		SCO|Caldera UnixWare
+		Solaris 2.x, 7, 8 and 9 (except for some VxFS versions;
+					 see the "Why doesn't Solaris
+					 lsof report VxFS path name
+					 components?" section for more
+					 information)
+		Solaris 10 (early builds) Tru64 UNIX
+
+	As far as I can determine, AFS path lookups don't share in
+	kernel name cache operations, so lsof can't identify open AFS
+	path name components.  Apparently Solaris VxFS versions 4 and
+	above don't share in kernel name cache operations, either, so
+	lsof can't display path name components for those open files.
+
+	Since the size of the kernel name cache is limited and the
+	cache is in constant flux, it does not always contain the names
+	of all components in an open file's path; sometimes it contains
+	none of them.
+
+	Lsof reports the file system directory name and whatever
+	components of the file's path it finds in the cache, starting
+	with the last component and working backwards through the
+	directories that contain it.  If lsof finds no path
+	components, lsof reports the file system device name instead.
+
+	When lsof does report some path components in the NAME
+	column, it prefixes them with the file system directory
+	name, followed by " -- ", followed by the components --
+	e.g., /usr -- sys/path.h for /usr/include/sys/path.h.  The
+	" -- " is omitted when lsof finds all the path name components
+	of a file's name.
+
+	The PSTAT-based HP-UX lsof relies on kernel name cache
+	contents, too, even though its information comes to lsof
+	via pstat() function calls.  Consequently, PSTAT-based
+	HP-UX lsof won't always report full paths, but may use the
+	" -- " partial path name notation, or may occasionally
+	report no path name at all but just the file system mounted-on
+	directory and device names.
+
+	Lsof can't obtain path name components from the kernel name
+	caches of the following dialects:
+
+	    AIX
+
+	Only the Linux kernel records full path names in the
+	structures it maintains about open files; instead, most
+	kernels convert path names to device and node number doublets
+	and use them for subsequent file references once files have
+	been opened.
+
+	To convert the device and node number doublet into a
+	complete path name, lsof would have to start at the root
+	node (root directory) of the file system on which the node
+	resides, and search every branch for the node, building
+	possible path names along the way.  That would be a time
+	consuming operation and require access to the raw disk
+	device (usually implying setuid-root permission).
+
+	If the prospect of all that local disk activity doesn't
+	concern you, think about the cost when the device is
+	NFS-mounted.
+
+	Try using the file system mount point and node number lsof
+	reports as parameters to find -- e.g.,
+
+	    $ find <mount_point> -inum <node_number> -print
+
+	and you may get an appreciation of what a file system
+	directory tree search would cost.
+
+3.3.1	Why do lsof -r reports show different path names?
+
+	When you run lsof with its repeat (``-r'') option, you may
+	notice that the extent to which it reports path names for
+	the same files may vary from cycle to cycle.  That happens
+	because other processes are making kernel calls affecting
+	the cache and causing entries to be removed from and added
+	to it.
+
+3.3.2	Why does lsof report the wrong path names?
+
+	Under some circumstances lsof may report an incorrect path
+	name component, especially for files in a rapidly changing
+	directory like /tmp.
+
+	In a rapidly changing directory, like /tmp, if the kernel
+	doesn't clear the cache entry when it removes a file, a
+	new file may be given the same keys and lead lsof to believe
+	that the old cache entry with the same keys belongs to the
+	new file.
+
+	Lsof tries to avoid this error by purging duplicate entries
+	from its copy of the kernel name cache when they have the
+	same device and inode number, but different names.
+
+	This error is less likely to occur in UNIX dialects where the
+	keys to the name cache are node address and possibly a
+	capability ID.  The Apple Darwin, Digital UNIX, FreeBSD, HP-UX,
+	NEXTSTEP, OPENSTEP, Solaris, Tru64 UNIX, and UnixWare dialects
+	use node address.  Apple Darwin, FreeBSD, NetBSD, OpenBSD,
+	Tru64 UNIX, and also use a capability ID to further identify
+	name cache entries.
+
+3.3.3	Why doesn't lsof report path names for unlinked (rm'd) files?
+
+	When lsof gets path name components from the kernel's name
+	cache, it does not report the path names of a file that has
+	been unlinked from its parent directory -- e.g., deleted via
+	rm, or the unlink() system call -- even when some process may
+	still hold the file open; lsof reports only the file system's
+	mounted-on directory and device.  That's because path name
+	components are removed from the kernel name cache when the file
+	is unlinked.
+
+	Unlinked open files are sometimes used by applications for
+	temporary, but invisible storage (i.e., ls won't show them,
+	and no other process can open them.)  However, they may
+	occasionally consume disk space to excess and cause concern
+	for a system administrator, who will be unable to locate
+	them with find, ls, du, or other tools that rely on finding
+	files by examining the directory tree.
+
+	By using lsof's +L option you can see the link count of
+	open files -- in the NLINK column.  An unlinked file will
+	have an NLINK value of zero.  By using the option +L1 you
+	can tell lsof to display only files whose link count is
+	less than one (i.e., zero).
+
+	There are some UNIX dialect-specific exceptions to lsof's
+	inability to report unlinked path names.  They are described in
+	the answer to the "When will lsof report path names for deleted
+	files?" question.
+
+3.3.4	Why doesn't lsof report the "correct" hard linked file path
+	name?
+
+	When lsof reports a rightmost path name component for a
+	file with hard links, the component may come from the
+	kernel's name cache.  Since the key which connects an open
+	file to the kernel name cache may be the same for each
+	differently named hard link, lsof may report only one name
+	for all open hard-linked files.   Sometimes that will be
+	"correct" in the eye of the beholder; sometimes it will
+	not.  Remember, the file identification keys significant
+	to the kernel are the device and node numbers, and they're
+	the same for all the hard linked names.
+
+3.3.5	When will lsof report path names for deleted files?
+
+	Lsof will report path names for deleted files for two
+	dialects:  Linux and later builds of Solaris 10.
+
+	Deleted Linux path names are reported by default and have
+	"(deleted)" at their ends.
+
+	The display of Solaris 10 deleted path names may be selected
+	with the -X option.  When selected they are also reported with
+	"(deleted)" at their ends.
+
+3.4	Why is lsof so slow?
+
+	Lsof may appear to be slow if network address to host name
+	resolution is slow.  This can happen, for example, when the
+	name server is unreachable, or when a Solaris PPP cache daemon
+	is malfunctioning.
+
+	To see if name lookup is causing lsof to be slow, turn it off
+	with the ``-n'' option.
+
+	Port service name lookup or portmap registration lookup may
+	also be causes of slow-down.  To suppress port service name
+	lookup, specify the ``-P'' option.
+
+	Lsof doesn't usually make direct portmap calls -- only when +M
+	is specified, or when HASPMAPENABLED is defined during lsof
+	construction.  (The lsof help panel, produced with `lsof -h`
+	will display the default portmap registration reporting
+	state.)  The quickest first step in checking if lsof is slow
+	because of the portmapper is to use lsof's ``-M'' option.
+
+	Lsof may be slow if UID to login name lookups are slow.
+	Suppress them with ``-l''.
+
+	On dialects where lsof uses the kernel name cache, try
+	disabling its use with ``-C''.  (You can tell if lsof uses the
+	kernel name cache by looking for ``-C'' in lsof's ``-h''
+	output.)  Of course, disabling kernel name cache use will mean
+	that lsof won't report full or partial path names, just file
+	system and character device names.
+
+	If you're just interested in the open files of one process, try
+	using the ``-p <Process-ID>'' option to limit lsof to that
+	process.  (The ``-p'' option may also be followed with a list
+	of Process-IDs.)
+
+	If you're interested in including or excluding certain
+	commands, try lsof's "-c[^]cmd" option.
+
+	If you're interested in certain Internet TCP and UDP states
+	(e.g., ESTABLISHED) or in excluding some (e.g., CLOSE_WAIT),
+	try lsof's "-s p:s" option, available where shown on the lsof
+	help output, obtained with -h or -?.  More information on it
+	may be found in the answer to the "How are protocol state name
+	exclusion and inclusion used?" question.
+
+	Your UNIX dialect may not support "-s p:s" and its associated
+	performance improvments to Internet-only file processing.  You
+	can find more information on those topics in the answer to the
+	"Why doesn't my dialect support state name exclusion and
+	inclusion?" question.
+
+	Older AIX lsof may be slow to start because of its oslevel
+	identity comparison.  (Newer AIX lsof uses uname(2).)  See the
+	"Why does AIX lsof start so slowly?" and "Why does lsof warn
+	"compiled for x ... y; this is z.?" sections for more
+	information.
+
+3.5	Why doesn't lsof's setgid or setuid permission work?
+
+	If you install lsof on an NFS file system that has been
+	mounted with the nosuid option, lsof may not be able to
+	use the setgid or setuid permission you give it, complaining
+	it can't open the kernel memory device -- e.g., /dev/kmem.
+
+	The only solution is to install lsof on a file system that
+	doesn't inhibit setgid or setuid permission.
+
+3.6	Does lsof have security problems?
+
+	I don't think so.  However, lsof does usually start with
+	setgid permission, and sometimes with setuid-root permission.
+	Any program that has setgid or setuid-root permission,
+	should always be regarded with suspicion.
+
+	Lsof drops setgid power, holding it only while it opens
+	access to kernel memory devices (e.g., /dev/kmem, /dev/mem,
+	/dev/swap).  That allows lsof to bypass the weaker security
+	of access(2) in favor of the stronger checks the kernel
+	makes when it examines the right of the lsof process to
+	open files declared with -k and -m.  Lsof also restricts
+	some device cache file naming options when it senses the
+	process has setuid-root power.
+
+	On a few dialects lsof requires setuid-root permission
+	during its full execution in order to access files in the
+	/proc file system.  These dialects include:
+
+	    DC/OSx 1.1 for Pyramid systems
+	    Reliant UNIX 5.4[34] for Pyramid systems
+
+	When lsof runs with setuid-root permission it severely
+	restricts all file accesses it might be asked to make with
+	its options.
+
+	The device cache file (typically .lsof_hostname in the home
+	directory of the real user ID that executes lsof) has 0600
+	modes.  (The suffix, hostname, is the first component of
+	the host's name returned by gethostname(2).)  However, even
+	when lsof runs setuid-root, it makes sure the file's
+	ownerships are changed to that of the real user and group.
+	In addition, lsof checks the file carefully before using
+	it (See the question "How do I disable the device cache
+	file feature or alter it's behavior?" for a description of
+	the checks.); discards the file if it fails the scrutiny;
+	complains about the condition of the file; then rebuilds
+	the file.
+
+	See the 00DCACHE file of the lsof distribution for more
+	information about device cache file handling and the risks
+	associated with the file.
+
+3.7	Will lsof show remote hosts using files via NFS?
+
+	No.  Remember, lsof displays open files for the processes
+	of the host on which it runs.  If the host on which lsof
+	is running is an NFS server, the remote NFS client processes
+	that are accessing files on the server leave no process
+	records on the server for lsof to examine.
+
+3.8	Why doesn't lsof report locks held on NFS files?
+
+	Generally lock information held by local processes on remote
+	NFS files is not recorded by the UNIX dialect kernel.  Hence,
+	lsof can't report it.
+
+	One exception is some patch levels of Solaris 2.3, and all
+	versions of Solaris 2.4 and above.  Lsof for those dialects
+	does report on locks held by local processes on remotely
+	mounted NFS files.
+
+3.8.1	Why does lsof report a one byte lock on byte zero as a full
+	file lock?
+	
+	When a process has a lock of length one, starting at byte
+	zero, lsof can't distinguish it from a full file lock.
+	That's because most UNIX dialects represent both locks the
+	same way in their file lock (flock or eflock) structures.
+
+3.9	Why does lsof report different values for open files on the
+	same file system (the automounter phenomenon)?
+
+	On UNIX dialects where file systems may be mounted by an
+	automounter with the ``direct'' type, lsof may sometimes
+	report difference DEVICE, SIZE/OFF, INODE and NAME values
+	when asked to report files open on the file system.
+
+	This happens because some files open on the file system --
+	e.g., the current directory of a shell that changed its
+	directory to the file system as the file system's first
+	reference -- may be characterized in the kernel with
+	temporary automounter node information.  The cd doesn't
+	cause the file system to be mounted.
+
+	A subsequent reference to the file system -- e.g., an ls
+	of any place in it -- will cause the file system to be
+	mounted.  Processes with files open to the mounted file
+	system are characterized in the kernel with data that
+	reflects the mounted file system's parameters.
+
+	Unfortunately some kernels (e.g., some versions of Solaris
+	2.x) don't revisit the process that did only a change-directory
+	for the purpose of updating the data associated with the
+	open directory file.  The file continues to be characterized
+	with temporary automounter information until it does another
+	directory change, even a trivial ``cd .''.
+
+	Lsof will report on both reference types, when supplied
+	the file system name as an argument, but the data lsof
+	reports will reflect what it finds in the kernel.  For the
+	different types lsof will display different data, including
+	different major and minor device numbers in the DEVICE
+	column, different lengths in the SIZE/OFF column, different
+	node numbers in the INODE column, and slightly different
+	file system names in the NAME column.
+
+	In contrast, fuser, where available, can only report on
+	one reference type when supplied the file system name as
+	an argument.  Usually it will report on the one that is
+	associated with the mounted file system information.  If
+	the only reference type is the temporary automounter one,
+	fuser will often be silent about it.
+
+3.10	Why don't lsof and netstat output match?
+
+	Lsof and netstat output don't match because lsof reports
+	the network information it finds in open file system objects
+	-- e.g., socket files -- while netstat often gets its
+	information from separate kernel tables.
+
+	The information available to netstat may describe network
+	activities never or no longer associated with open files,
+	but necessary for proper network state machine operation.
+
+	For example, a TCP connection in the FIN_WAIT_[12] state
+	may no longer have an associated open file, because the
+	connection has been closed at the application layer and is
+	now being closed at the TCP/IP protocol layer.
+
+3.10.1	Why can't lsof find accesses to some TCP and UDP ports?
+
+	Lsof stands for LiSt Open Files.  If there is no open file
+	connected to a TCP or UDP port, lsof won't find it.  That's
+	the most common reason why lsof doesn't find a port netstat
+	might report open.
+
+	One reason I've found on some UNIX dialects is that their
+	kernels set aside TCP and UDP ports for communicating with
+	support activities, running in application layer servers
+	-- the automounter daemons, and the NFS biod and nfsd
+	daemons are examples.  Netstat may report the ports are in
+	use, but lsof doesn't.
+
+	Another reason is that netstat may also be able to report
+	a port is open on a particular dialect, because it uses a
+	source of data different from what lsof uses -- e.g.,
+	netstat might examine kernel tables or use streams messages
+	to MIB2, while lsof relies on the information it finds in
+	open file structures and their descendants.
+
+	Sometimes it's possible to search the data netstat and lsof
+	use.  For example, on Linux /proc/tcp and /proc/udp can be
+	examined.  There might an entry there for a particular
+	protocol and port, but if the line on which the port appears
+	doesn't have an inode number that matches an inode number
+	of an open file, lsof won't be able to identify the process
+	using the port.
+
+	This is a tough question to which there is no easy answer.
+
+3.11	Why does lsof update the device cache file?
+
+	At the end of the lsof output you may see the message:
+
+	    lsof: WARNING: /Homes/abe/.lsof_vic was updated.
+
+	In this message /Homes/abe/.lsof_vic is the path to the
+	private device cache file for login abe.  (See 00DCACHE.)
+
+	Lsof issues this message when it finds it necessary to
+	recheck the system device directory (e.g., /dev or /devices)
+	and rebuild the device cache file during the open file
+	scan.  Lsof may need to do these things it finds that a
+	device directory node has changed, or if it cannot find a
+	device in the cache.
+
+3.12	Why doesn't lsof report state for UDP socket files?
+
+	Lsof reports UDP TPI connection state -- TS_IDLE (Idle),
+	TS_BOUND (Bound), etc. -- for some, but not all dialects.
+	TPI state is stream-based TCP/IP information that isn't
+	available in many dialects.
+
+	A fairly weak general rule is if netstat(1) reports UDP
+	TPI state, lsof may be able to report it, too.  But don't
+	be surprised if lsof fails to report UDP TPI state for your
+	dialect.  Other factors influence lsof's ability to report
+	UDP TPI state, including the availability of state number
+	data in kernel structures, and state number to state name
+	conversion data.
+
+3.13	I am editing a file with vi; why doesn't lsof find the file?
+
+	Classic implementations of vi usually don't keep open the file
+	being edited.  (Newer ones may do so in order to maintain an
+	advisory lock.)  Instead classic vi opens the file, makes a
+	temporary copy (usually in /tmp or /usr/tmp), and does its work
+	in that file.  When you save the file being edited from a
+	classic vi implementation, it reopens and rewrites the file.
+
+	During a classic vi session, except for the brief periods when
+	vi is reading or rewriting the file, lsof won't find an open
+	reference to the file from the vi process, because there is
+	none.
+
+3.14	Why doesn't lsof report TCP/TPI window and queue sizes for my
+	dialect?
+
+	Lsof only reports TCP/TPI window sizes for Solaris, because
+	only its netstat reports them.  The intent of providing
+	TCP/TPI information in lsof NAME column output is to make
+	it easier to match netstat output to lsof output.
+
+	In general lsof only reports queue sizes for both TCP and
+	UDP (TPI) connections on BSD-derived UNIX dialects, where
+	both sets of values appear in kernel socket queue structures.
+	SYSV-derived UNIX dialects whose TCP/IP implementations
+	are based on streams generally provide only TCP queue sizes,
+	not UDP (TPI) ones.
+
+	While you may find that netstat on some SYSV-derived UNIX
+	dialects with streams TCP/IP may report UDP (TPI) queue
+	sizes, you will probably also find that the sizes are always
+	zero -- netstat supplies a constant zero for UDP (TPI)
+	queue sizes to make its headers align the same for TCP and
+	UDP (TPI) connections.  Solaris seems to get it right --
+	i.e., its netstat does not report UDP (TPI) queue sizes.
+
+	When in doubt, I chose to avoid reporting UDP (TPI) queue
+	sizes for UNIX dialects whose netstat-reported values I
+	knew to be a constant zero or whose origin I couldn't
+	determine.  OSR is a dialect in this category.
+
+3.14.1	Why doesn't lsof report socket options, socket states, and TCP
+	flags and values for my dialect?
+
+	The lsof -T argument, 'f', that selects the reporting of socket
+	options, socket states and TCP flags was implemented at lsof
+	revision 4.71 for the following UNIX dialects, providing the
+	indicated information:
+
+	    AIX 4.3.2 and 5.1 and above
+		All socket options and values, socket states, and TCP
+		flags and values described in lsof(8) are reported.
+	    Apple Darwin 7.2 and above
+		All socket options and values, socket states, and TCP
+		flags and values described in lsof(8) are reported.
+	    Digital UNIX and Tru64 UNIX 4.0
+		All socket options and values, socket states, and TCP
+		flags and values described in lsof(8) are reported.
+	    FreeBSD 4.9 and above
+		All socket options and values, socket states, and TCP
+		flags and values described in lsof(8) are reported.
+	    HP-UX 11.00 (/dev/kmem-based lsof)
+		All socket options and values are reported.  No socket
+		states are reported.  Only the TF_NODELAY TCP flag and
+		the TF_MSS value are reported.
+	    HP-UX 11.11 and iiiv2 (PSTAT-based lsof)
+		All socket options and values, and socket states are
+		reported.  No TCP flags or values are reported.
+	    Linux
+		No socket options and values, socket states, or TCP
+		flags and values are reported.  The support for "-Tf"
+		could not be added to Linux, because socket options,
+		socket states, and TCP flags and values are not
+		available via the /proc file system.
+	    NetBSD 1.6G and above
+		All socket options and values, socket states, and TCP
+		flags and values described in lsof(8) are reported.
+	    OpenBSD 3.4 and above
+		All socket options and values, socket states, and TCP
+		flags and values described in lsof(8) are reported.
+	    OPENSTEP 4.2
+		All socket options and values, socket states, and TCP
+		flags and values described in lsof(8) are reported.
+	    OpenUNIX 8
+		All socket options and values, socket states, and TCP
+		flags and values described in lsof(8) are reported.
+	    SCO OpenServer Release 5.0.6
+		All socket options and values, socket states, and TCP
+		flags and values described in lsof(8) are reported.
+	    Solaris 2.6, 8 and above
+		The socket option display is limited to BROADCAST,
+		DEBUG, DGRAM_ERRIND, DONTROUTE and OOBINLINE.  Socket
+		values are limited to KEEPALIVE and LINGER.  No socket
+		states are reported.  The TCP DELACK, NODELAY and
+		SENTFIN flags are reported.  The TCP MSS value is
+		reported.
+	    UnixWare 7.1.[134]
+		All socket options and values, socket states, and TCP
+		flags and values described in lsof(8) are reported.
+
+3.14.2	Why doesn't lsof report the partial listen queue connection
+	count for my dialect?
+
+	The reporting of partial listen queue connections was added to
+	-Tf processing at lsof revision 4.76.  Currently it is reported
+	for these dialects:
+
+	    AIX 4.3.2
+		This dialect is no longer supported, so no attempt
+		was made to add partial listen queue length support
+		for it.
+	    AIX 5.1 and above
+		Partial listen queue information is available.
+	    Apple Darwin 7.2 and above
+		Partial listen queue information is available.
+	    Digital UNIX 4.0
+		This dialect is no longer supported, so no attempt
+		was made to add partial listen queue length support
+		for it.
+	    FreeBSD 4.9 and above
+		Partial listen queue information is available.
+	    HP-UX 11.00 (/dev/kmem-based lsof)
+		No partial listen queue information is available.
+	    HP-UX 11.11 and iiiv2 (PSTAT-based lsof)
+		No partial listen queue information is available.
+	    Linux
+		No partial listen queue information is available.
+	    NetBSD 1.6G and above
+		Partial listen queue information is available.
+	    OpenBSD 3.4 and above
+		Partial listen queue information is available.
+	    OPENSTEP 4.2
+		Partial listen queue information is available.
+	    OpenUNIX 8
+		This dialect is no longer supported, so no attempt
+		was made to add partial listen queue length support
+		for it.
+	    SCO OpenServer Release 5.0.6
+		No partial listen queue information is available.
+	    Solaris 2.6, 8 and above
+		Partial listen queue information is available.
+	    Tru64 UNIX 5.0
+		This dialect is no longer supported, so no attempt
+		was made to add partial listen queue length support
+		for it.
+	    Tru64 UNIX 5.1
+		Partial listen queue information is available.
+	    UnixWare 7.1.[134]
+		Partial listen queue information is available.
+
+
+3.15	What does "no more information" in the NAME column mean?
+
+	When lsof can find no successor structures -- a gnode,
+	inode, socket, or vnode -- connected to the file structure
+	of an open descriptor of a process, it reports "no more
+	information" in the NAME column.  The TYPE, DEVICE, SIZE/OFF,
+	and INODE columns will be blank.
+
+	Because the file structure is supposed to contain a pointer
+	to the next structure of a file's processing support, if
+	the pointer is NUL, lsof can go no further.
+
+	Some UNIX dialects have file structures for system processes
+	-- e.g., the sched process -- that have no successor
+	structure pointers.  The "no more information" NAME will
+	commonly appear for these processes in lsof output.
+
+	It may also be the case that lsof has read the file structure
+	while it is being assembled and before a successor structure
+	pointer value has been set.  The "no more information" NAME
+	will again result.
+
+	Unless lsof output is filled with "no more information"
+	NAME column messages, the appearance of a few should be no
+	cause for alarm.
+
+3.16	Why doesn't lsof find a process that ps finds?
+
+	If lsof fails to display open files for a process that ps
+	indicates exists, there may be several reasons for the
+	difference.
+
+	The process may be a "zombie" for which ps displays the
+	"(defunct)" state.  In that case, the process has exited
+	and has no open file information lsof can display.  It does
+	still have a process structure, sufficient for the needs
+	of ps.
+
+	Another possible explanation is that kernel tables and
+	structures may have been changing when lsof looked for the
+	process, making lsof unable to find all relevant process
+	structures.  Try repeating the lsof request.
+
+3.17	Why doesn't -V report a search failure?
+
+	The usual reason that -V won't report a search failure is
+	that lsof located the search item, but was prevented from
+	listing it by an option that doesn't participate in search
+	failure reporting.
+
+	For example, this lsof invocation:
+
+	    $ lsof -V -i TCP@foobar -a -d 999
+
+	won't report it can't find the Internet address TCP@foobar,
+	even if there is an open file connected to that address,
+	unless the open file also has a file descriptor number of
+	999 (the ``-a -d 999'' options).
+
+	Compile-time options can also affect -V results in much the
+	same way.  For example, if HASSECURITY and HASNOSOCKSECURITY
+	are defined at compile time, this lsof invocation, run by a
+	non-root user:
+
+	    $ lsof -V -c inetd
+
+	won't report that it can't find the inetd command, even if
+	there is a process running the inetd command, because the
+	HASSECURITY and HASNOSOCKSECURITY options prevent the
+	listing of all but the socket files of another user, and
+	no socket file selector (e.g., "-i") was specified.
+
+
+3.18	Portmap problems
+
+3.18.1	Why isn't a name displayed for the portmap registration?
+
+	When portmap registration reporting is enabled, any time
+	there is a registration for a local TCP or UDP port, lsof
+	displays it in square brackets, following the port number
+	or service name -- e.g., ``:1234[name]'' or ``:name[100083]''.
+
+	The TCP or UDP port number or service number (what follows
+	the `:') is displayed under the control of the lsof -P
+	option.  The registration identity is held by the portmapper
+	and may be a name or a number, depending on how the
+	registration's owner declared it.  Lsof reports what the
+	port map holds and cannot derive a registration name from
+	a registration number.
+
+	Lsof can be compiled with registration reporting enabled
+	or disabled by default, under the control of the HASPMAPENABLED
+	#define (usually in machine.h).  The lsof help panel (`lsof
+	-h`) will show the default.  Lsof is distributed with
+	reporting disabled by default.
+
+3.18.2	How can I display only portmap registrations?
+
+	Lsof doesn't have an option that will display only TCP or
+	UDP ports with portmap registrations.  The +M option only
+	enables the reporting of registration information when
+	Internet socket files are displayed; +M doesn't select
+	the displaying of Internet socket files -- the -i option
+	does that.
+
+	This simple lsof pipe to grep will do the job:
+
+		$ lsof -i +M | grep "\["
+
+	This works because -i selects Internet socket files, +M
+	enables portmap registration reporting, and only output
+	lines with opening square brackets will have registrations.
+
+	When portmap registration reporting is enabled by default,
+	because the lsof builder constructed it that way, +M is
+	not necessary.  (The lsof help panel, produced with `lsof
+	-h` will display the default portmapper registration
+	reporting state.)  However, specifying +M when reporting
+	is already enabled is acceptable, as is specifying -M when
+	reporting is already disabled.
+
+	Digression: lsof will accept `+' or `-' as a prefix to most
+	options.  (That isn't documented in the man page or help
+	panel to reduce confusion and complexity.)  The -i option
+	is as acceptable as +i, so the above example could be
+	written a little more tersely as:
+
+		$ lsof +Mi | grep "\["
+	
+	But be careful to use the ``Mi'' ordering, since ``iM''
+	implies M is an address argument to `i'.
+
+3.18.3	Why doesn't lsof report portmap registrations for some ports?
+
+	Lsof reports portmap registrations for local TCP and UDP
+	ports only.  It identifies local ports this way:
+
+	*  The port appears in the local address section of the
+	   kernel structure that contains it.
+
+	*  The port appears in the foreign address section of a
+	   kernel structure whose local and foreign Internet
+	   addresses are the same.
+
+	*  The port appears in the foreign address section of a
+	   kernel address structure whose Internet address is
+	   INADDR_LOOPBACK (127.0.0.1).
+
+	Following these rules, lsof ignores foreign portmapped
+	ports.  That's done for reasons of efficiency and possible
+	security prohibitions.  Contacting all remote portmappers
+	could take a long time and be blocked by network difficulties
+	(i.e., be inefficient).  Many firewalls block portmapper
+	access for security reasons.
+
+	Lsof may occasionally ignore portmap registration information
+	for a legitimate local port by virtue of its local port
+	rules.  This can happen when a port appears in the foreign
+	part of its kernel structure and the local and foreign
+	Internet addresses don't match (perhaps because they're on
+	different interfaces), and the foreign Internet address
+	isn't INADDR_LOOPBACK (127.0.0.1).
+
+3.18.4	Why doesn't lsof report portmap registrations for some Solaris
+	versions?
+
+	In some versions of Solaris -- 9 and 10 are known to exhibit
+	this problem -- lsof is unable to display portmap registrations.
+
+	This portmap registration reporting failure occurs when the
+	Solaris netconfig field (in /etc or etc/inet) has its first two
+	non-comment lines enabling tcp6 and udp6.  When netconfig is
+	configured in that fashion, lsof's attempt to read the portmap
+	via an RPC function fails.
+
+	I don't have an explanation for the failure, but this comment
+	in the netconfig(4) man page appears to have some bearing on
+	the problem:
+
+	    # The following two entries starting with udp6 and tcp6 are
+	    # meant to be used for IPv6. If you have Ipv6 enabled on your
+	    # machine then you can uncomment these two lines to enable
+	    # RPC and NFS to use the Ipv6 stack.
+	    ...
+	    #udp6  tpi_clts      v  inet6  udp  /dev/udp6  -
+	    #tcp6  tpi_cots_ord  v  inet6  tcp  /dev/tcp6  - "
+
+	My interpretation of that comment is that there is a different
+	RPC interface to the portmap when IPv6 is enabled.  However, I
+	can't find any documentation on it in the RPC man pages.  If
+	anyone has information on it, please send it to me at
+	<abe@purdue> and put "lsof Solaris portmap" in the subject
+	line.
+
+	A work-around may be to move the ucp6 and tcp6 lines after the
+	udp and tcxp lines in netconfig.  I don't know if that change
+	has any unacceptable consequences, but it works for me on my
+	Solaris 9 test system, and I have a report that it also works
+	on Solaris 10.
+
+
+3.19	Why is `lsof | wc` bigger than my system's open file limit?
+
+	There is a strong temptation to count open files by piping
+	lsof output to wc.  If your purpose is to compare the number
+	you get to some Unix system parameter that defines the
+	number of open files your system can have, resist the
+	temptation.
+
+	One reason is that lsof reports a number of "files" that
+	don't occupy Unix file table space -- current working
+	directories, root directories, jail directories, text files,
+	library files, memory mapped files are some.  Another reason
+	is that lsof can report a file shared by more than one
+	process that itself occupies only one file table slot.
+
+	If you want to know the number of open files that occupy
+	file table slots, use the +ff option and process the lsof
+	output's FILE_ADDR column information with standard Unix
+	tools like cut, grep, sed, and sort.
+
+	You might also consider using use lsof's field output with
+	+ff, selecting the file struct address with -FF, and
+	processing the output with an AWK or Perl script.  See the
+	list_fields.awk, list_fields.perl, and shared.perl5 scripts
+	in the scripts/ subdirectory of the lsof distribution for
+	hints on file struct post-processing filters.
+
+3.20	Why doesn't lsof report file offset (position)?
+
+	Lsof won't report a file offset (position) value if the -s
+	option (without parameters) has been specified, or if the
+	dialect doesn't support the displaying of file offset
+	(position).  (Note that on selected dialects the help output,
+	obtained with -h or -?, may show that the -s option can also be
+	supplied the "p:s" parameters; for more information on that
+	addition, see the answer to the "How are protocol state name
+	exclusion and inclusion used?" question.)
+
+	That lsof is reporting only file size is indicated by the
+	fact that the appropriate column header says SIZE instead
+	of SIZE/OFF.
+
+	If lsof doesn't support the displaying of file offset
+	(position) -- e.g., for Linux /proc-based lsof -- the -h
+	or -? output panel won't list the -o option.
+
+	Sometimes the availability of file offset information
+	depends on the dialect's kernel.  This is particularly true
+	for socket file offsets.
+	
+	Maintenance of offsets for pseudo-terminal devices varies
+	by UNIX dialect and is related to how the dialect kernel
+	implements pseudo-terminal support.  Kernels like AIX, for
+	example, that short-circuit the transfer of data between
+	socket and pseudo devices to reduce TCP/IP daemon interrupt
+	rates won't advance offsets in the TCP/IP daemon socket
+	files.  Instead they will advance offsets in the open
+	standard I/O files of the shell child precess where the
+	pseudo-terminal devices are used.
+
+	When in doubt about the behavior of lsof in reporting file
+	offset information, do some carefully measured experiments,
+	consult the lsof sources, or contact me at <abe@purdue.edu>
+	to discuss the matter.  Please follow the reporting guidelines
+	in the "How do I report an lsof bug?" section of this FAQ.
+
+3.20.1	What does lsof report for size when the file doesn't really have
+	one?
+
+	When a file has no true size -- e.g., it's a socket, a
+	FIFO, or a pipe -- lsof tries to report the information it
+	finds in the kernel that describes the contents of associated
+	kernel buffers.
+
+	Thus, for example, size for most TCP/IP files is socket
+	buffer size.  The size of the socket read buffer is reported
+	for read-only files; the size of the write buffer for
+	write-only files; and the sum of the buffers sizes for
+	read-write files.
+
+3.21	Problems with path name arguments
+
+3.21.1	How do I ask lsof to search a file system?
+
+	You can ask lsof to search for all open files on a file
+	system by specifying its mounted path name as an lsof
+	argument -- e.g.,
+
+	    $ lsof /
+
+	Output of the mount command will show file system mounted
+	path names.  It will also show the mounted-on device path
+	for the file system.
+
+	If the mounted-on device is a block device (the permission
+	field in output of `ls -l <device>` starts with a `b/),
+	you can specify it's name, too -- e.g.,
+
+	    $ lsof /dev/sd0a
+
+	If the mounted-on device isn't a block device -- for example,
+	some UNIX dialects call a CD-ROM device a character device
+	(ls output starts with a `c') -- you can force lsof to
+	assume that the specified device names a file system with
+	the +f option -- e.g.,
+
+	    $ lsof +f -- /dev/sd0a
+	
+	(Note: you must use ``--'' after +f or -f if a file name
+	follows immediately, because  +f and -f can be followed by
+	characters that specify flag output selections.)
+
+	When you use +f and lsof can't match the device to a file
+	system, lsof will issue a complaint.
+
+	The +f option may be used in some dialects to ask lsof to
+	search for an NFS file system by its server name and server
+	mount point.  If the mount application reports an NFS file
+	system mounted-on value that way, then this sample lsof
+	request should work.
+
+	    $ lsof +f -- fleet:/home/fleet/u5
+
+	Finally, you can use -f if you don't want a mounted file
+	system path name to be considered a request to report all
+	open files on the file system.  This is useful when you
+	want to know if anyone is using the file system's mounted
+	path name.  This example directs lsof to report on open
+	access to the `/' directory, including when it's being used
+	as a current working or root directory.
+
+	    $ lsof -f -- /
+
+	The lsof -f option performs the same function as -f does
+	in some fuser implementations.  However, since the lsof -c
+	option was chosen for another purpose before the `f' option
+	was added to lsof, +f was selected as the analogue to the
+	fuser -c option.  (Sorry for the potential confusion.)
+
+3.21.2	Why doesn't lsof find all the open files in a file system?
+
+	Lsof may not find all the open files in a file system for
+	several reasons.
+
+	First, some processes with files open on the file system
+	may have been changing status when lsof examined the process
+	table, and lsof "missed" them.  Remember, the kernel changes
+	much faster than lsof can respond to the changes.
+
+	Second, be sure you have specified the file system correctly.
+	Perhaps you specified a file instead.  You can use lsof's
+	-V option to have lsof report in detail on what it couldn't
+	find.  Make sure the report for the file system you specified
+	says "file system."  Here's some -V output:
+
+	    $ /lsof -V /tmp ./lsof.h ./lsof
+	    COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF  INODE NAME
+	    lsof    2688  abe  txt   VREG 18,1,7  1428583 226641 ./lsof
+	    lsof    2689  abe  txt   VREG 18,1,7  1428583 226641 ./lsof
+	    lsof: no file use located: ./lsof.h
+
+	You can also use lsof's +f option to force it to consider
+	a path name as a file system.  If lsof can't find a file
+	system by the specified name, it will issue a complaint --
+	e.g.,
+
+	    $ lsof +f -- /usr
+	    lsof: not a file system: /usr
+	
+	(/usr is a directory in the / file system.)
+
+3.21.3	Why does the lsof exit code report it didn't find open files
+	when some files were listed?
+
+	Sometimes lsof will list some open files, yet return a
+	non-zero exit code, suggesting it hasn't found all the
+	specified files.
+
+	The first thing you should when you suspect lsof is incorrect
+	is to repeat the request, adding the -V option.  In the
+	resulting report you may find that your file system
+	specification really wasn't a file system specification,
+	just a file specification.
+
+	Finally, if you specify two files or two file systems twice,
+	lsof will credit all matches to the first of the two and
+	believe that there were no matches for the second.  It's
+	possible to specify a single file system twice with different
+	path names by using both its mounted directory path name
+	and mounted-one device name.
+
+	    $ lsof +f -V spcuna:/sysprog /sysprog
+	    COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF  INODE NAME
+	    ksh     11092  abe  cwd   VDIR 39,0,1     1536 226562 /sysprog
+	    (spcuna:/sysprog)
+	    ...
+	    lsof: no file system use located: spcuna:/sysprog
+	
+	All matches were credited to /sysprog; none to spcuna:/sysprog.
+
+3.21.4	Why won't lsof find all the open files in a directory?
+
+	When you give lsof a simple directory path name argument
+	(not a file system mounted-on name), you are asking it to
+	search for processes that have the directory open as a
+	file, or as a process-specific directory -- e.g., root or
+	current working directory.
+
+	If you want to list instances of open files inside the
+	directory, you need to specify the individual path names
+	of those files, or use the lsof +D and +d options.
+
+	See the answer to the question "Why are the +D and +d
+	options so slow?" before you use +D or +d casually.
+
+	See the answer to the question "Why do the +D and +d options
+	produce warning messages?" for an explanation of some
+	process authority limitations of +D and +d.
+
+3.21.5	Why are the +D and +d options so slow?
+
+	The +D and +d options cause lsof to build a path name search
+	list for a specified directory.  +D causes lsof to descend
+	the directory to its furthest subdirectory, while +d
+	restricts it to the top level.  In both cases, the specified
+	directory itself is included in the search list.  In both
+	symbolic links are ignored.
+
+	Building such a search list can take considerable time,
+	especially when the specified directory contains many files
+	and subdirectories -- lsof must call the system readlink()
+	and stat() functions for each file and directory.  Storing
+	the search list can cause lsof to use more than its normal
+	amount of dynamic memory -- each file recorded in the search
+	list consumes dynamic memory for its path name, characteristics,
+	and search linkages.  Using the list means lsof must search
+	it for every open file in the system.
+
+	Building the search list for a directory specified on some
+	file systems can be slow -- e.g., for an NFS directory with
+	many files.  Some file systems have special logging features
+	that can introduce additional delays to the building of
+	the search list -- e.g., NFS logging, or logging on a
+	Solaris UFS file system.  The bottom line is that slow
+	search list construction may not be so much an lsof problem
+	as a file system problem.  (Hint: if you're using Solaris
+	UFS logging, consider specifying the "logging,noatime"
+	option pair to reduce the number of atime writes to the
+	UFS logging queue and disk.)
+
+	A somewhat risky way to speed up lsof's building of the
+	search list is to use lsof's ``-O'' option.  It forces lsof
+	to do all system calls needed to build the search list
+	directly, rather than in a child process.  While direct
+	system calls are much faster, they can block in the kernel
+	-- e.g., when an NFS server stops responding -- stopping
+	lsof until the kernel operation unblocks.
+
+	As an example of the load +D can impose, consider that an
+	`lsof +D /` on a lightly loaded NeXT '040 cube with a 1GB
+	root file system disk took 4+ minutes of real time.  It
+	also generated several hundred error messages about files
+	and directories the lsof process didn't have permission to
+	access with stat(2).
+
+	The bottom line is that +D and +d should be used cautiously.
+	+D is more costly than +d for deeply nested directory trees,
+	because of the full directory descent it causes.  So use
+	+d where possible.  And you might need to consider the
+	performance of the file system that holds the directory
+	you name with +d or +D.
+
+	In view of these warnings, when is it appropriate to use
+	+D or +d?  Probably the most appropriate time is when you
+	would specify the directory's contents to lsof with a shell
+	globbing construct -- e.g., `lsof *`.  If that's what you
+	need to do, `lsof +d .` is probably more efficient than
+	having the shell produce a directory list, form it into an
+	argument vector, and pass the vector to lsof for it to
+	unravel.
+
+	See the answer to the question "Why do the +D and +d options
+	produce warning messages?" for an explanation of some
+	process authority limitations of +D and +d.
+
+3.21.6	Why do the +D and +d options produce warning messages?
+
+	+D and +d option processing is limited by the authority of
+	the lsof process -- i.e., lsof can only examine (with
+	lstat(2) and stat(2)) files the owner of the process can
+	access.
+
+	If the ownership, group membership, or permissions of the
+	specified directory, file within it, or directory within
+	it prevents the owner of the lsof process from using lstat(2)
+	or stat(2) on it, lsof will issue a warning message, naming
+	the path and giving the system's (lstat(2's or stat(2)'s)
+	reason (errno explanation text) for refusing access.
+
+	As an example, assume user abc has a subdirectory in /tmp,
+	owned by abc and readable, writable and searchable by only
+	its owner.  If user def asks lsof to search for all /tmp
+	references with +D or +d, lsof will be unable to lstat(2)
+	or stat(2) anything in abc's private subdirectory, and will
+	issue an appropriate warning.
+
+	Lsof warnings can usually be suppressed with the -w option.
+	However, using -w with +D or +d means that there will be
+	no indication why lsof couldn't find an open reference to
+	a restricted directory or something contained in it.
+
+	Hint: if you need to use +D or +d and avoid authority
+	warnings, and if you have super-user power, su and use lsof
+	with +D or +d as root.
+
+3.22	Why can't my C compiler find the rpcent structure definition?
+
+	When you try to compile lsof your compiler may complain
+	that the rpcent structure is undefined.  The complaints
+	may look like this:
+
+	    >print.c: In function `fill_portmap': 
+	    >print.c:213: dereferencing pointer to incomplete type
+	    >...
+
+	The most likely cause is that someone has allowed a BIND
+	installation to update /usr/include/netdb.h (or perhaps
+	/usr/include/rpc/netdb.h), removing the rpcent structure
+	definition that lsof expects to find there.
+
+	Only Solaris has an automatic work-around.  (See dlsof.h
+	in dialects/sun.).  The Solaris work-around succeeds because
+	there is another header file, <rpc/rpcent.h>, with the rpcent
+	structure definition, and there is a Solaris C pre-processor
+	test that can tell when the BIND <netdb.h> is in place and
+	hence <rpc/rpcent.h> must be included.
+
+	Doubtlessly there are similar work-arounds possible in
+	other UNIX dialects whose header files have been "touched"
+	by BIND, but in general I recommend restoration of the
+	vendor's <netdb.h> and any other header files BIND might
+	have replaced.  (I think BIND replaces <resolv.h>,
+	<sys/bitypes.h>, <sys/cdefs.h> -- and maybe others.)
+
+3.23	Why doesn't lsof report fully on file "foo" on UNIX dialect
+	"bar?"
+
+	Lsof sometimes won't report much information on a given
+	file, or may even report an error message in its NAME
+	column.  That's usually because the file is of a special
+	type -- e.g., in a file system specific to the UNIX dialect
+	-- and I haven't used a system where the file appeared
+	during my testing.
+
+	If you encounter such a situation, send me e-mail at
+	<abe@purdue.edu> and we may be able to devise an addition to
+	lsof that will report on the file in question.  Please follow
+	the reporting guidelines in the "How do I report an lsof bug?"
+	section of this FAQ.  Make sure "lsof" appears in the
+	"Subject:" line so my e-mail filter won't classify your letter
+	as Spam.
+
+3.24	Why do I get a complaint when I execute lsof that some library
+	file can't be found?
+
+	On systems where the LIBPATH (or the equivalent) environment
+	variable is used to record the library search path in
+	executable files when they are built, an incorrect value
+	may make it impossible for the system to find the shared
+	libraries needed to load lsof for execution.
+
+	This may be particularly true on systems like AIX >= 4.1.4,
+	where the lsof Makefile takes the precautionary step of
+	using the -bnolibpath loader flag to insure that the path
+	to the private static lsof library is not recorded in the
+	lsof binary.  Should LIBPATH be invalid when lsof is built,
+	it will be recorded in the lsof binary as the default
+	library path search order and lead to an inability to find
+	libraries when lsof is executed.
+
+	So, if you get missing library complaints when you try to
+	execute lsof, check LIBPATH, or whatever environment variable
+	is used on your system to define library search order in
+	executable files.  Use the tools at your disposal to look
+	at the library paths recorded in the lsof binary -- e.g.,
+	chatr on HP-UX, dump on AIX, ldd on Solaris.
+
+	Make sure, too, that when the correct library search path
+	has been recorded in the executable file, the required
+	library files exist at one or more of the search paths.
+
+
+3.25	Why does lsof complain it can't open files?
+
+	When lsof begins execution, unless it has been asked to
+	report only help or version information, typically it will
+	attempt to access kernel memory and symbol files -- e.g.,
+	/unix, /dev/kmem.  Even though lsof needs only permission
+	to open these files for reading, read access to them might
+	be restricted by ownerships and permission modes.
+
+	So the first step to diagnosing lsof problems with opening
+	files is to use ls(1) to examine the ownerships and permission
+	modes of the files that lsof wants to open.  You may find
+	that lsof needs to be installed with some type of special
+	ownership or permission modes to enable it to open the
+	necessary files for reading.  See the "Installing Lsof"
+	section of 00README for more information.
+
+3.26	Why does lsof warn "compiled for x ... y; this is z."?
+
+	Unless warnings are suppressed (with -w) or the kernel
+	identity check symbol (HASKERNIDCK) definition has been
+	deleted, all but one lsof dialect version (exception:
+	/proc-based Linux lsof) compare the identity of the running
+	kernel to that of the one for which lsof was constructed.
+	If the identities don't match, lsof issues a warning like
+	this:
+
+	    lsof: WARNING: compiled for Solaris release 5.7; this is 5.6.
+
+	Two kernel identity differences can generate this warning
+	-- the version number and the release number.
+
+	Build and running identity differences are usually significant,
+	because they usually indicate kernels whose structures are
+	different -- kernel structures commonly change at dialect
+	version releases.  Since lsof reads data from the kernel
+	in the form of structures, it is sensitive to changes in
+	them.  The general rule is that an lsof compiled for one
+	UNIX dialect version will not work correctly when run on
+	a different version.
+
+	There are three work-arounds: 1) use -w to suppress the
+	warning -- and risk missing other warnings; 2) permanently
+	disable the identity check by deleting the definition of
+	HASKERNIDCK in the dialect's machine.h header file -- with
+	the same risk; or 3) rebuild lsof on the system where it
+	is to be run.  (Deleting HASKERNIDCK can be done with the
+	Customize script or by editing machine.h.)
+
+	Generally checking kernel identity is a quick operation
+	for lsof.  However, it is potentially slow under AIX, where
+	lsof must run /usr/bin/oslevel.  To speed up lsof, use -w
+	to suppress the /usr/bin/oslevel test.  See "Why does AIX
+	lsof start so slowly?" for more information.
+
+3.27	How can I disable the kernel identity check?
+
+	The kernel identity check is controlled by the HASKERNIDCK
+	definition.  When it is defined, most dialects (exclusion:
+	/proc-based Linux lsof) will compare the build-time kernel
+	identity with the run-time one.
+
+	To disable the kernel identity check, disable the HASKERNIDCK
+	definition in the dialect's machine.h header file.  The
+	Customize script can be used to do that in its section
+	about the kernel identity check.
+
+	Caution: while disabling the kernel identity check may
+	result in smaller lsof startup overhead, it comes with the
+	risk of executing an lsof that may produce warning messages,
+	error messages, incorrect output, or no output at all.
+
+3.28	Why don't ps(1) and lsof agree on the owner of a process?
+
+	Generally the user ID lsof reports in its USER column is
+	the process effective user ID, as found in the process
+	structure.  Sometimes that may not agree with what ps(1)
+	reports for the same process.
+
+	There are sundry reasons for the difference.  Sometimes
+	ps(1) uses a different source for process information,
+	e.g., the /proc file system or the psinfo structure.
+	Sometimes the kernel is lax or confused (e.g., Solaris
+	2.5.1) about what ID to report as the effective user ID.
+	Sometimes the system carries only one user ID in its process
+	structure (some BSD derivatives), leaving lsof no choice.
+
+	The differences between lsof and ps(1) user identifications
+	should be small and normally it will be apparent that the
+	confusion is over a process whose application has changed
+	to an effective user ID different from the real one.
+
+3.29	Why doesn't lsof find an open socket file whose connection
+	state is past CLOSE_WAIT?
+
+	TCP/IP connections in states past CLOSE_WAIT -- e.g.,
+	FIN_WAIT_1, CLOSING, LAST_ACK, FIN_WAIT_2, and TIME_WAIT
+	-- don't always have open files associated with them.  When
+	they don't, lsof can't identify them.  When the connection
+	state advances from CLOSE_WAIT, sometimes the open file
+	associated with the connection is deleted.
+
+3.30	Why don't machine.h definitions work when the surrounding
+	comments are removed?
+
+	The machine.h header files in dialect subdirectories have
+	some commented-out definitions like:
+
+	    /* #define HASSYSDC "/your/choice/of/path */
+
+	You can't simply remove the comments and expect the definition
+	to work.  That's intended to make you think about what
+	value you are assigning to the symbol.  The assigned value
+	might have a system-specific convention.  HASSYSDC, for
+	example, might be /var/db/lsof.dc for FreeBSD, but it might
+	be /var/adm/lsof.dc for Solaris.
+
+	Symbols defined in the lsof documentation are described in
+	00PORTING, other machine.h comments, and other lsof
+	documentation files.  HASSYSDC, for example, is discussed
+	in 00DCACHE.  When comments and documentation don't suffice,
+	consult the source code for hints on how the symbol is
+	used.
+
+3.31	What do "can't read inpcb at 0x...", "no protocol control
+	block", "no PCB, CANTSENDMORE, CANTRCVMORE", etc. mean?
+
+	Sometimes lsof will report "can't read inpcb at 0x00000000",
+	"no protocol control block", "no PCB, CANTSENDMORE,
+	CANTRCVMORE" or a similar message in the NAME column for
+	open TCP socket files.  These messages mean the file's socket
+	structure lacks a pointer to the INternet Protocol Control
+	Block (inpcb) where lsof expects to find connection addresses
+	-- local and foreign ports, local and foreign IP addresses.
+	The socket file has probably been submitted to the shutdown(2)
+	function for processing.
+
+	In some implementations lsof issues the "no PCB, CANTSENDMORE,
+	CANTRCVMORE" message, which tries to explain the absence
+	of a protocol control block by showing the socket state
+	settings that have been made by the shutdown(2) function.
+
+	If a non-zero address follows the "0x" in the "can't read
+	inpcb" message, it means lsof couldn't read inpcb contents
+	from the indicated address in kernel memory.
+
+3.32	What do the "unknown file system type" warnings mean?
+
+	Lsof may report a message similar to"
+
+	    unknown file system type, v_op: 0x10472f10
+
+	in the NAME column for some files.
+
+	This means that lsof has encountered a vnode for the file
+	whose operation switch address (from v_op) references a
+	file system type for which there is no support in lsof.
+	After lsof identifies the file system type, it uses
+	pre-compiled code to locate the file system specific node
+	for the file where lsof finds information like file size,
+	device number, node number, etc.
+
+	To get some idea of what the file system type might be,
+	use nm on your kernel symbol file to locate the symbol name
+	that corresponds to the v_op address -- e.g., on Solaris
+	do:
+
+	    $ nm -x /dev/ksyms | grep 0x10472f10
+	    0x10472f10 ... |file_system_name_vnodeops
+
+	Where "file_system_name" is the clue to the unsupported
+	file system.
+
+	Lsof doesn't use the v_op address to identify file system
+	types on all dialects.  Sometimes it uses an index number
+	it finds in the vnode.  It will translate that symbol to
+	a short name in the warning message -- e.g., "nfs3" -- if
+	possible.
+
+3.33	Installation
+
+3.33.1	How do I install lsof?
+
+	There is no "standard" way to install lsof.  Too much
+	depends on local conditions for me to be able to provide
+	working install rules in the lsof make files.  (The skeleton
+	install rules you will find just give "hints.")  See the
+	"Installing Lsof" section of 00README for a fuller explanation.
+
+	To install lsof you will need to consider these questions:
+
+	*  Who should be able to use lsof?  (See HASSECURITY and
+	    HASNOSOCKSECURITY in the "Security" section of 00README.)
+
+	*  Where should lsof be installed?  This is a decision
+	   mostly dictated by local conditions.  Somewhere in
+	   /usr/local -- etc/ or sbin/ -- is a common choice.
+
+	*  What permissions should I give the lsof executable?
+	   The answer to this varies by dialect.  The make files
+	   have install rules that give hints.  The "Installing
+	   Lsof" section of 00README gives information, too.
+
+	*  What if I want to install lsof in a shared file system
+	   for machines that require different lsof configurations?
+	   See the next question and answer, "How do I install a
+	   common lsof when I have machines that need differently
+	   constructed lsof binaries?"
+
+3.33.2	How do I install a common lsof when I have machines that
+	need differently constructed lsof binaries?
+
+	A dilemma that faces some system administrators when they
+	install lsof in a shared file system -- e.g., NFS -- is
+	that they must have different lsof executables for different
+	systems.
+
+	The answer is to build an lsof wrapper script that is
+	executed in place of lsof.  The script can use system
+	commands to determine which lsof binary should be executed.
+
+	Consider this example.  You have HP-UX machines with 32
+	and 64 bit kernels that share the /usr/local/sbin directory
+	where you want to install lsof.  Consequently, on each
+	system you must use a different lsof executable, built for
+	the system's bit size.  (That's because lsof reads kernel
+	structures, sized by the kernel's bit size.)
+
+	One answer is to install three things in /usr/local/sbin:
+	1) a 32 bit lsof as lsof32; 2) a 64 bit lsof as lsof64;
+	and 3) an lsof script.  The script might look like this
+	one, based on work by Amir J. Katz:
+
+	    #!/bin/sh
+	    x=`/usr/bin/getconf KERNEL_BITS`  # returns 32 or 64
+	    if /usr/bin/test "X$x" = "X32"
+	    then
+	      lsof32 $*
+	    else
+	      if /usr/bin/test "X$x" = "X64"
+	      then
+		lsof64 $*
+	      else
+		echo "Can't determine which lsof executable to use;"
+		echo "getconf KERNEL_BITS says: $x"
+		exit 1
+	      fi
+	    fi
+
+	Solaris users should consult "How do I install lsof for
+	Solaris 7, 8 or 9?" for information on a similar trick
+	using the Solaris isaexec command.
+
+	Users of other dialects might be able to use a command like
+	uname(1) that can identify a distinguishing feature of the
+	system to be incorporated in pre-installed lsof executable
+	names.  For example, use `uname -r` and install binaries
+	with suffixes that match `uname -r` output.
+
+3.34	Why do lsof 4.53 and above reject device cache files built
+	by earlier lsof revisions?
+
+	When lsof revisions 4.53 run and encounter a device cache
+	file built by an earlier revision, it will reject the file
+	and build a new one.  The rejection will be advertised with
+	these messages:
+
+	    lsof: WARNING: no /dev device in <name>: 2 sections
+	    ...
+	    lsof: WARNING: created device cache file: <name>
+
+	This happens because the header line of the device cache
+	file was changed at revision 4.53 to contain the number of
+	the device on which the device directory resides.  The old
+	device cache file header line -- the "2 sections" line in
+	the above warning message, node reads "2 sections, dev=600".
+
+	This is not a serious problem, since lsof automatically
+	rebuilds the device cache file with the correct header
+	line.
+
+3.35	What do "like block special" and "like character special" mean
+	in the NAME column?
+
+	When lsof comes across an open block or character file
+	whose device, raw device and inode place it somewhere other
+	than /dev (or /devices), lsof doesn't report the /dev (or
+	/devices) name in the NAME column.  Instead lsof reports
+	the file system name and device or path name in the NAME
+	column and parenthetically adds "like block special <path>"
+	or "like character special <path>".
+
+	The value for <path> will point to a block or character
+	device in /dev (or /devices) whose raw device number matches
+	that of the open file being reported, but whose device
+	number or node number (or both) don't match.
+
+	Such an open file is connected to a device node that has
+	been created in a directory other than /dev (or /devices.)
+	See mknod(8) for information on how such nodes are created.
+	(Generally one needs root power to create device nodes with
+	mknod.)
+
+3.36	Why does an lsof make fail because of undefined symbols?
+
+	When lsof is compiled via the `make` step and the final
+	load step fails because of missing symbols, the problem
+	may not be lsof.  The problem may be that ld, called by
+	the compiler as part of the `make` step, can't find some
+	library that lsof needs.
+
+	First check the last compiler line of the make operation
+	-- e.g., the last line with cc or gcc in it before the
+	undefined symbol report -- for loader arguments, i.e.,
+	ones beginning with "-l".  Except for "-llsof" the rest
+	name system libraries.  ("-L./lib" precedes "-llsof" to
+	tell the loader its location.)
+
+	Check that all the named system libraries exist.  Look in
+	/lib and /usr/lib as a start, but that may not be the only
+	place system libraries live.  Consult your dialect's
+	documentation, e.g., the compiler and loader man pages,
+	for other possible locations.
+
+	If some system library doesn't exist, that may mean it was
+	never installed or was removed.  You'll have to re-install
+	the missing library.
+
+	You may find that all the system libraries lsof uses exist.
+	Your next step might be to use nm and grep to see if any
+	of them contain the undefined symbols.
+
+	    $ nm library | grep symbol
+
+	If the undefined symbol exists in some library named by
+	the lsof make step, then you might have a problem with some
+	environment variable that controls the load step.  The most
+	common is LD_LIBRARY_PATH.  It may have a setting that
+	causes ld to ignore a directory containing a library lsof
+	names.  If this is the case, try unsetting LD_LIBRARY_PATH
+	in the environment of the ld process -- e.g., do:
+
+	    $ unset LD_LIBRARY_PATH
+	or
+	    % unsetenv LD_LIBRARY_PATH
+
+	Consult your ld man page for other environment variables
+	that might affect library searching -- e.g., LIBPATH, LPATH,
+	SHLIB_PATH, etc.
+
+	If the undefined function doesn't exist in any libraries
+	lsof names, check other libraries.  See if the function
+	has a man page that names its library.  If the latter is
+	true, please let me know, because that is an lsof problem
+	I need to fix.
+
+	If none of these solutions work for you, send me some
+	documentation via e-mail at <abe@purdue.edu>.  Include `uname
+	-a` output, the output of the lsof `Configure ...` and `make`
+	steps, and the contents of the environment in force when the
+	`make` step was executed -- e.g., `env` or `printenv` output.
+	If you've located the libraries lsof names, send me that
+	information, too.  Make sure "lsof" appears in the "Subject:"
+	line so my e-mail filter won't classify your letter as Spam.
+
+3.37	Command Regular Expressions (REs)
+
+3.37.1	What are basic and extended regular expressions?
+
+	Lsof's ``-c'' option allows the specification of regular
+	expressions (REs), enclosed in two slash ('/') characters and
+	followed by these modifiers:
+	
+	    b	the RE is a basic RE.
+	    i	ignore case.
+	    x	the RE is an extended RE (the default).
+	
+	Note: the characters of the regular expression may need to
+	be quoted to prevent their expansion by the shell.
+
+	Example: this RE is an extended RE that matches exactly
+	four characters, whose third may be an upper ('O') or lower
+	case ('o') oh:
+
+	    -c /^..o.$/i
+
+	For simplicity's sake, an RE that is acceptable to egrep(1)
+	is usually called an extended RE.
+
+	REs suitable for the old line editor, ed(1), are often
+	called basic REs (and sometimes also called obsolete).
+
+	These are some ways basic REs usually differ from extended
+	REs.  (There are other differences.)
+
+	*  `|', `+', `?', '{', and '}' are ordinary characters.
+
+	*  `^' is an ordinary character except at the beginning of
+	   the RE.
+
+	*  `$' is an ordinary character except at the end of the
+	   RE.
+
+	*  `*' is an ordinary character if it appears at the
+	   beginning of the RE.
+
+	For more information on REs and the distinction between
+	basic and extended REs, consult your dialect's man pages
+	for ed(1), egrep(1), sed(1), and possibly regex(5) or
+	regex(7).
+
+3.37.2	Why can't I put a slash in a command regular expression?
+
+	Since a UNIX command name is the last part of a path to
+	the command's executable, the lsof command regular expression
+	(RE) syntax uses slash ('/') to mark the beginning and end
+	of an RE.  Slash may not appear in the RE and the `\'
+	back-slash escape is ineffective for "hiding" it.
+
+	More likely than not, if you try to put a slash in an lsof
+	command RE, you'll get this response:
+
+	    $ lsof -s/.\// ...
+	    lsof: invalid regexp modifier: /
+
+	Lsof is complaining the the first character it found after
+	the second slash isn't an lsof command RE modifier -- 'b',
+	'i', or 'x'.
+
+3.37.3	Why does lsof say my command regular expression wasn't found?
+
+	When you use both forms of lsof's -c option --
+	``-c <command>'' and ``-c /RE/[m]'' -- and ask that lsof
+	do a verbose search (``-V''), you may be surprised that
+	lsof will say that the regular expression wasn't found.
+
+	This can happen if the ``-c <command>'' form matches first,
+	because then the ``-c/RE/[m]'' test will never have been
+	applied.  For example:
+
+	    $ ./lsof -clsof -c/^..o.$/ -V -adcwd
+	    COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
+	    lsof    7850  abe  cwd   VDIR    6,0     2048 96442 / (/dev/sd0a)
+	    lsof: no command found for regex: ^..o.$
+
+	The ``-clsof'' option matched first, so the ``-c/^..o.$/
+	option wasn't tested.
+
+3.38	Why doesn't lsof report on shared memory segments?
+
+	Lsof reports on shared memory segments only if they're
+	associated with an open file.  That's consistent with lsof's
+	mission -- to LiSt Open Files.  Shared memory segments with
+	no file associations aren't open files.
+
+	That's not to say that a report on shared memory segments
+	and their associated processes wouldn't be useful.  But it
+	calls for a new tool, not more baggage for lsof.
+
+3.39	Why does lsof report two instances of itself?
+
+	When you ask lsof to report all open files and it has
+	permission to do so, you may see two lsof processes in the
+	output.  The processes are connected via pipes -- e.g.,
+	here's an HP-UX 11 example.
+
+	    COMMAND     PID USER   FD   TYPE     DEVICE ...
+	    ...
+	    lsof      29450  abe    7w  PIPE 0x48732408 ...
+	    lsof      29450  abe    8r  PIPE 0x48970808 ...
+	    ...
+	    lsof      29451  abe    6r  PIPE 0x48732408 ...
+	    lsof      29451  abe    9w  PIPE 0x48970808 ...
+
+	The first process will usually be the lsof you initiated;
+	the second, an lsof child process that is used to isolate
+	its parent process from kernel functions that can block --
+	e.g., readlink() or stat().
+
+	Information to and from the kernel functions is exchanged
+	via the two pipes.  When the parent process detects that
+	the child process has become blocked, it attempts to kill
+	the child.  Depending on the UNIX dialect that may succeed
+	or fail, but the parent won't be blocked in any event.
+
+	See the "BLOCKS AND TIMEOUTS" and "AVOIDING KERNEL BLOCKS"
+	sections of the lsof man page for more information on why
+	the child process is used and how you can specify lsof
+	options to avoid it.  (Caution: that may be risky.)
+
+3.40	Why does lsof report '\n' in device cache file error messages?
+
+	Lsof revisions prior to 4.58 may report '\n' in error
+	messages it delivers about problems in the device cache
+	file -- e.g.,
+
+	    lsof: WARNING: no ...: 4 sections\n
+
+	That's deliberately done to show the exact contents of the
+	device cache file line about which lsof is complaining,
+	including its terminating NL (New Line) '\n' character.
+	In the above example the line in the device cache file
+	causing the lsof complaint contains "4 sections" and ends
+	with a '\n'.
+
+	At revision 4.58 and above, device cache error messages
+	like the one in the above example have been changed to
+	read:
+
+	    lsof: WARNING: no ...: line "4 sections"
+
+	The terminal '\n' is no longer reported, the line contents
+	are enclosed in double quote marks ('"'), and the word
+	"line" has been added as a prefix to denote that what
+	follows is a line from the device cache file.
+
+3.41	Kernel Symbol and Address Problems
+
+3.41.1	What does "lsof: WARNING: name cache hash size length error: 0"
+	mean?
+
+	When run on some systems, lsof may issue this warning:
+
+	    lsof: WARNING: name cache hash size length error: 0
+
+	That is an example from a FreeBSD system where lsof reads
+	the kernel's _nchash variable and finds its value is zero.
+
+	Similar warnings include:
+
+	    WARNING: kernel name cache size:
+	    WARNING: can't read kernel's name cache:
+	    WARNING: no name cache address
+	    WARNING: name cache hash size length error:
+	    WARNING: unusable name cache size:
+
+	These warnings are issued when lsof is attempting to read
+	the kernel's name cache information.  They are usually the
+	result of a mis-match between the addresses for kernel
+	symbols lsof gets via nlist(2) and the addresses in use by
+	the kernel.
+
+	Lsof usually gets kernel symbol addresses from what it
+	believes to be the kernel boot file.  In FreeBSD, for
+	example, that's the path returned by getbootfile(3), usually
+	/kernel.  The boot file can have other names in other UNIX
+	dialects -- /unix, /vmunix, /bsd, /netbsd, /mach, /stand/vmunix,
+	etc.
+
+	Lsof will get incorrect (mismatched) addresses from the
+	boot file if it has been replaced by a newer one which
+	hasn't yet been booted -- e.g., if this is done in FreeBSD:
+
+	    # mv /kernel /kernel.OLD
+	    # mv /kernel.NEW /kernel
+
+	Until the FreeBSD system is rebooted, the booted kernel is
+	/kernel.OLD, but getbootfile() says it is /kernel.  If
+	symbol addresses important to lsof in /kernel.OLD and
+	/kernel don't match, the lsof WARNING messages result.
+
+3.41.2	Why does lsof produce "garbage" output?
+
+	Kernel name cache warnings may not be the only sign that
+	lsof is using incorrect symbol addresses to read kernel
+	values.  If there's no reasonable test lsof can make on
+	what it reads from the kernel, it may issue other warnings
+	or even report nonsensical results.
+
+	The warnings may appear on STDERR, such as:
+
+	    lsof: can't read proc table info
+
+	Or the warnings may appear in the NAME column as messages
+	saying lsof can't read or interpret some kernel structure --
+	e.g.,
+
+	    ... NAME
+	    ... can't read file struct from 0x12345
+
+	One possible work-around is to point lsof's kernel symbol
+	address gathering at the proper boot file.  That can be
+	done with lsof's -k option -- e.g.,
+
+	    $ lsof -k /kernel.OLD
+
+	The best work-around is to make sure the standard boot file
+	is properly sited -- e.g., if you've moved a new /kernel
+	in place, boot it.
+
+3.42    Why does lsof report open files when run as super user that
+	it doesn't report when run with lesser privileges?
+
+	The most likely cause is that the HASSECURITY option was
+	selected when the lsof executable was built.
+
+	If HASSECURITY is defined when lsof is built, and lsof is
+	run with the privileges of a non-ROOT user, it will only
+	list open files belonging to the user.  The same lsof
+	executable, when run with root user privileges, will list
+	all open files.
+
+	However, if HASSECURITY and HASNOSOCKSECURITY are both
+	defined when lsof is built, lsof will list open files
+	belonging to the user and will also list anyone else's open
+	socket files, provided their listing is selected with the
+	"-i" option.
+
+	So first ask yourself if the process whose open files lsof
+	won't list belong to a user other than the one under which
+	you're running lsof, and are not open socket files.  If
+	either is true, use lsof's help (-h or -?) option and look
+	for a line near the bottom of the help panel that says:
+
+	    "... can list all files..."
+
+	If the leading "..." says "Only root" then HASSECURITY was
+	defined when lsof was built.  If the trailing "..." says
+	", but anyone can list socket files" then HASNOSOCKSECURITY
+	was also defined.
+
+	Should you want an lsof not built with HASSECURITY defined,
+	rerun the lsof Configure script.  If you let Configure do
+	customization, make sure you answer 'n' when it asks if
+	you want to enable HASSECURITY and HASNOSOCKSECURITY.  If
+	you don't need to do customization, you can rebuild lsof
+	with the "-n" option to Configure.  Here's an example of
+	such a rebuild sequence:
+
+	    $ Configure -clean
+	    $ Configure -n <dialect-abbreviation>
+	    $ make
+
+	More information on the HASSECURITY and HASNOSOCKSECURITY
+	options may be found in the "Security" section of the
+	00README file of the lsof distribution.
+
+3.43	Test Suite Problems
+
+3.43.1	Errors all tests can report:
+
+3.43.1.1 Why do tests complain "ERROR!!!  can't execute ../lsof"?
+
+	All tests in the test suite expect an executable lsof file
+	to exist in the tests parent directory, ../lsof.
+
+	If there's none there, the tests/Makefile has a rule to
+	make it, but there are probably circumstances where that
+	rule may fail.
+
+	The work-around is to re-Configure and re-make lsof, then
+	run the test suite.
+
+3.43.1.2 Why do tests complain "ERROR!!! can't find ..." a file?
+
+	Many tests create (or use from a supplied environment
+	variable path) a test file and use lsof to find it.  When
+	lsof can't file the file, the tests report the error with
+	messages of the form:
+
+	    ERROR!!!  can't find ... : <some file path>
+	 or
+	    ERROR!!!  lsof couldn't find ...
+	
+	These type of error messages mean that the lsof field output
+	delivered to the test didn't contain a file that the test
+	could identify as the one it intended lsof to find.  It
+	might also mean that the process information -- command
+	name, PID or parent PID -- didn't match what the test
+	expected.
+
+	This could imply a bug in the test or a bug in lsof.  Try
+	using lsof to find a known file that is open.  For example,
+	while in the tests sub-directory, do this:
+
+	    $ sleep 30 < Makefile
+	    $ ../lsof Makefile
+
+	If lsof doesn't report that Makefile is open, then the
+	fault may be with lsof.  If lsof reports the file is open,
+	search further in the test code for the failure cause.
+
+3.43.1.3 Why do some tests fail to compile?
+
+	If a test suite program fails to compile, it may be because
+	I've never had an opportunity to compile the test on the
+	particular UNIX version you are using.
+
+	See Appendix B in 00TEST for a list of the UNIX dialects
+	where the test suite has been validate.
+
+3.43.1.4 Why do some tests always fail?
+
+	There are several tests in the optional group that have
+	conflicting or special requirements:
+
+	    LTbigf      needs a dialect and file system that support
+			large files.
+
+	    LTlock      won't work if the tests/ sub-directory is
+			on an NFS file system.
+
+	    LTnfs       won't work if the tests/ sub-directory is
+			not on an NFS file system.
+
+	So for two tests in particular, LTlock and LTnfs, one will
+	generally fail.
+
+	Some failing tests can be run successfully by supplying to
+	them a path to the appropriate type of file system with
+	the -p option.
+
+3.43.1.5 Why does the test suite say it hasn't been validated on
+	 my dialect?
+
+	When you use the default rule of the test suite's Makefile,
+	it may issue this complaint:
+
+	    $ cd tests
+	    $ make
+	    !!!WARNING!!!
+
+	    This dialect or its particular version may not have
+	    been validated with the lsof test suite.  Consequently
+	    some tests may fail or may not even compile.
+
+	    !!!WARNING!!!
+
+	You are then given the opportunity to answer 'y' to have
+	the test suite operation continue.
+
+	This message means that the tests/TestDB file in the tests
+	sub-directory doesn't show that the test suite has been
+	run with the combination of compiler flags found in
+	tests/config.cflags.  The tests might nor run; they may
+	encounter compiler failures.
+
+	See 00TEST for more information on the UNIX dialects where
+	the test suite has been validated and on the workings of
+	TestDB and its supporting scripts.
+
+	When the tests/Makefile "auto" rule is used, the message
+	is more terse and the condition is fatal.
+
+	    This suite has not been validated on:
+
+		<dialect_description>
+
+	No opportunity to continue is offered.
+
+	The tests/Makefile "silent" rule will skip checking for
+	the validation footprint.
+
+3.43.1.6 Why do the tests complain they can't stat() or open()
+	 /dev/mem or /dev/kmem?
+
+	When the tests detect that lsof for the dialect reads its
+	information from kernel memory (i.e., the LT_KMEM definition
+	is present in tests/config.cflags), and when the lsof
+	executable path is ../lsof, the tests make sure they can
+	stat() and open() for read access the relevant kernel memory
+	devices, /dev/kmem and possibly /dev/mem.
+
+	If those stat() or open() operations fail, the tests issue
+	an error message and quit.  The message explains why the
+	system rejected the operation in terms of system "errno"
+	symbols and messages.  More often than not the explanation
+	will be that the process lacks permission to access the
+	indicated device node.
+
+	One work-around is to give the lsof executable being tested
+	the necessary permission -- e.g., via chgrp, chmod, etc.
+	-- and set its path in the LT_LSOF_PATH environment variable.
+	(See 00TEST.)
+
+	Another work-around is to make sure the process that runs
+	the tests has the necessary permissions -- e.g., run it as
+	root, or enable the process login to access the resources.
+	For example, I can run the tests on my personal work-station
+	because /dev/kmem and /dev/mem are readable by the "kmem"
+	group and my login is in that group.
+
+
+3.43.2	LTbigf test issues
+
+3.43.2.1 Why does the LTbigf test say that the dialect doesn't
+	 support large files?
+
+	Large file support is defined dialect by dialect in the
+	lsof source files and Configure script.  If large file
+	support isn't defined there, it isn't defined in the LTbigf
+	test.
+
+	If you think that's wrong for a particular dialect, contact me
+	via e-mail at <abe@purdue.edu>.  Make sure "lsof" appears in the
+	"Subject:" line so my e-mail filter won't classify your letter
+	as Spam.
+
+3.43.2.2 Why does LTbigf complain about operations on its config.LTbigf*
+	 file?
+
+	The LTbigf must be able to write a large file test (size
+	> 32 bits) and seek within it and the process file ulimit
+	size must permit the operation.  If the default location
+	for the test file, tests/, isn't on a file system enabled
+	for large file operations or if the process ulimit file
+	block size is too small, lsof will get file operation
+	errors, particularly when seeking
+
+	There may be a work-around.  Specify the path to a file
+	LTbigf can write in a file system enabled for large file
+	operations a the -poption.  Make sure that the ulimit file
+	block size permits writing a large file.  For example,
+	presuming /scratch23 is large-file-enabled, and presuming
+	you have permission to raise the ulimit file block size,
+	this shell commands will allow the LTbigf test to run on
+	AIX:
+
+	    $ ./LTbigf -p /scratch23/abe/bigfile
+
+	(Note: syntax for the ulimit command varies by dialect and
+	by shell.  Discovering the proper variant is left to the
+	reader.)
+
+	More information on this subject can be found in the LTbigf
+	description in the 00TEST file.  If course, the LTbigf.c
+	source file in tests/ is the ultimate source of information,
+
+3.43.2.3 Why does LTbigf warn that lsof doesn't return file offsets?
+
+	On some dialects (e.g., Linux) lsof can't report file
+	offsets, because the data access method underlying lsof
+	doesn't provide them.  If LTbigf knows that lsof can't
+	report file offsets for the dialect, it issues this warning:
+
+	    LTbigf ... WARNING!!!  lsof can't return file offsets
+			for this dialect, so offset tests have
+			been disabled.
+	
+	LTbigf then performs the size test and skips the offset
+	tests.
+
+	For more information see 00TEST and the "Why doesn't
+	/proc-based lsof report file offsets (positions)?" Q&A of
+	this file.
+
+3.43.3	Why does the LTbasic test complain "ERROR!!! lsof this ..."
+	and "ERROR!!!  lsof that ..."?
+
+	The LTbasic test program uses lsof to examine a running
+	lsof process.  It looks for the lsof current working
+	directory, executable (if possible), and kernel memory file
+	(if applicable).
+
+	Failures to find those things result in the LTbasic error
+	messages.  More information on how LTbasic produces the error
+	messages may be found in the LTbasic.c source file.
+
+	On HP-UX 11.11 and higher, for example, if the test's current
+	working directory is on a loopback (LOFS) file system, LTbasic
+	won't be able to find the current working directory of the lsof
+	process because of a bug in the HP-UX kernel.
+
+	The solution for that HP-UX problem is to install an HP-UX
+	patch.  See the answer to the "Why doesn't PSTAT-based lsof
+	report a CWD that is on a loopback (LOFS) file system?"
+	question for more information on the patch.
+
+3.43.4	NFS test issues
+
+3.43.4.1 Why does the LTnfs test complain "couldn't find NFS file ..."?
+
+	The LTnfs test must work with an NFS test file.  After it
+	opens the file it asks lsof to find it on an NFS file system.
+	If the file isn't on an NFS file system, lsof won't find it,
+	and the NFS test script complains and fails.
+
+	The work-around is to use -p option to supply a path to a
+	regular NFS file (not a directory)  that is on an NFS file
+	system that LTnfs can read.  Presuming /share/bin/file is
+	such a file and can be opened for reading by the LTnfs
+	test, this sample shell command could be used to run the
+	LTnfs test successfully:
+
+	    $ ./LTnfs -p /share/bin/file
+
+	(If the NFS file system is enabled for large files, the
+	NFS test will produce the error message described in the
+	following Q&A.)
+
+3.43.5	LTnlink test issues
+
+3.43.5.1 Why does the LTnlink test complain that its test file is on
+	 an NFS file system?
+
+	The LTnlink test may complain:
+
+	    LTnlink ... WARNING!!!  test file <path> is NFS mounted.
+
+	and then issue an explanation and a hint about using the
+	-p option.
+
+	The LTnlist test does this because of the way NFS file
+	links are managed when an NFS file is unlinked and the
+	unlinking process still has the file open.  Unlike with
+	files on a local file system, when an NFS file that is
+	still open is unlinked, its link count is not reduced.
+
+	The file name is changed to a name of the form .nfsxxxx
+	and the link count is left unchanged until the process
+	holding the file open closes it.  That's done by NFS so it
+	can keep proper track of the file on NFS clients and servers.
+
+	Since the link count isn't reduced when the LTnlink test
+	program closes the NFS test file it still has open, lsof
+	won't find it for LTnlink with a link count of zero.
+	Consequently, LTnlink disables that test section and issues
+	its warning.
+
+	The warning suggests that the unlink test section can be
+	run by giving LTnlink a path to a test file with the -p
+	option.  That path must name a file LTnlink can write and
+	unlink.  Presuming /scratch23/abe/nlinkfile is on a local
+	file system and the LTnlink test can write to it and unlink
+	it, this sample shell command can be used to run the complete
+	LTnlink test successfully:
+
+	    $ LTnlink -p /scratch23/abe/nlinkfile
+
+3.43.5.2 Why does LTnlink delay and report "waiting for link count
+	 update: ..."?
+
+	On some UNIX dialects and file system combinations the
+	updating of link count after a file has been unlinked can
+	be delayed.  Consequently, lsof won't be able to report
+	the updated link count to LTnlink for a while.
+
+	When lsof doesn't report the proper link count to LTnlink,
+	it sleeps and repeats the lsof call, using the "waiting
+	for link count update: ..." message as a signal that it is
+	waiting for the expected lsof response.  The wait cycle
+	duration is limited to approximately one minute.
+
+3.43.5.3 Why does LTnlink fail because of an unlink error?
+
+	LTnlink may fail with an error similar to:
+
+	    LTnlink ... ERROR!! unlink(<name>) failed: (Permission denied).
+
+	That message will be followed by a short explanation.
+
+	The error means that the kernel support for the file system on
+	which the file <name> resides does not allow a process to
+	unlink a file while it has the file open.  (When LTnlink is run
+	without the "-p path" option, it creates a <name> that begins
+	with "./config.LTnlink" and ends with the LTnlink process ID
+	number.)
+
+	An unlink failure of this type runs counter to original UNIX
+	file system behavior, but it has been observed on some file
+	system types, especially on the ZFS file system.
+
+	The work-around is to run LTnlink on a file system that allows
+	a process to unlink a file it has open.  Usually /tmp has that
+	support.  So, try running LTnlink this way:
+
+	    $ ./LTnlink -p /tmp/<name>
+	
+	where <name> is a unique name in /tmp of your choosing.  To
+	be safe, create a subdirectory in /tmp, named by your login:
+
+	    $ rm -f /tmp/<login>
+	    $ mkdir /tmp/<login>
+	    $ ./LTnlink -p /tmp/<login>/<name>
+
+3.43.6	LTdnlc test issues
+
+3.43.6.1 Why won't the LTdnlc test run?
+
+	Lsof is unable to access the DNLC cache on AIX, because the
+	kernel symbols for the DNLC aren't exported.  Contact IBM
+	to learn why that decision was made.
+
+	The LTdnlc test won't work on Apple Darwin because lsof
+	can't obtain reliable DNLC information.
+
+	The LTdnlc test may fail on other dialects.  Failure causes
+	include: a busy system with a DNLC that is changing rapidly;
+	path name components too large for the DNLC; a file system
+	-- e.g., NFS, /tmp, loopback -- which doesn't fully
+	participate in the DNLC; or DNLC limitations (Many DNLC
+	implementations will only store path name components if
+	they are 31 characters or less.)
+
+	If you suspect the file system doesn't fully participate
+	in kernel DNLC processing, as a work-around rebuild and
+	test lsof on one that does.
+
+3.43.6.2 What does the LTdnlc test mean by "... <path> found: 100.00%"?
+
+	Even when it succeeds the LTdnlc test will report:
+
+	  LTdnlc ... /export/home/abe/src/lsof4/tests found: 100.00%
+
+	This message means that the LTdnlc test asked lsof to find
+	the file at the indicated path five times and lsof found
+	the full path name in the indicated percentage of calls.
+	The LTdnlc test considers it a failure if the percentage
+	falls below 50.0%
+
+3.43.6.3 Why does the DNLC test fail?
+
+	The DNLC test may fail when some component of the lsof
+	tests/ sub-directory can't be cached by the kernel DNLC.
+	Some kernels have a limit on the length of individual
+	components (typically) 32.
+
+3.43.7	Why hasn't the test suite been qualified for 64 bit HP-UX
+	11 when lsof is compiled with gcc?
+
+	When I attempted to qualify lsof for HP-UX 11, compiled
+	with gcc 3.0, the LTsock test failed.  I traced the failure
+	to a gcc compilation error.  Because LTsock is an important
+	test, I didn't feel that the test suite was qualified if
+	it failed.
+
+	LTsock compiles and runs correctly on 64 bit HP-UX 11 when
+	compiled with HP's ANSI-C.
+
+3.43.8	LTszoff test issues
+
+3.43.8.1 Why does LTszoff warn that lsof doesn't return file offsets?
+
+	On some dialects (e.g., Linux) lsof can't report file
+	offsets, because the data access method underlying lsof
+	doesn't provide them.  If LTszoff knows that lsof can't
+	report file offsets for the dialect, it issues this warning:
+
+	    LTszoff ... WARNING!!!  lsof can't return file offsets
+			  for this dialect, so offset tests have
+			  been disabled.
+	
+	LTszoff then performs the size test and skips the offset
+	tests.
+
+	For more information see 00TEST and the "Why doesn't
+	/proc-based lsof report file offsets (positions)?" Q&A of
+	this file.
+
+3.43.9	LTlock test issues
+
+3.44	File descriptor list (the ``-d'' option) problems
+
+3.44.1	Why does lsof reject a ``-d'' FD list?
+
+	Lsof rejects ``-d'' FD lists that contain both exclusions
+	and inclusions with messages like:
+
+	    lsof: exclude in an include list: ^1
+	    lsof: include in an exclude list: 2
+
+	That's because ``-d'' FD lists are processed as ORed lists,
+	so it makes no sense for them to contain both exclusions
+	and inclusions.
+	
+	I.e.,, if a ``-d'' FD list were to contain ``^cwd,1'', the
+	``^cwd'' member is useless, because the ``1'' member
+	dominates by saying "include only FD 1".  That effectively
+	excludes ``cwd'' FD.
+
+	Note that lists may have multiple members of the same type,
+	exclude or include.  They are processed as an ORed set.
+	If an FD isn't excluded by any member of an exclude list,
+	it is selected.  If an FD is included by any member of an
+	include list, it is selected.
+
+3.44.2	Why are file descriptors other than those in my FD list
+	reported?
+
+	The FD list that follows ``-d'' excludes or includes file
+	descriptors, but unless the ``-a'' (AND) option is specified,
+	the FD list selections are ORed to the other selections.
+
+	For example, the following lsof command will cause all file
+	descriptors to be listed for the lsof command, and all but
+	the cwd descriptor for all other commands, probably not
+	what was intended.
+
+	    $ lsof -clsof -d^cwd
+
+	Hint: use ``-a'' -- e.g.,
+
+	    $ lsof -clsof -a -d^cwd
+
+3.45	How can I supply device numbers for inaccessible NFS file
+	systems?
+
+	When lsof can't get device numbers for inaccessible NFS file
+	systems via stat(2) or lstat(2), it attempts to get them from
+	the mount table's dev=xxx options.  Successes are reported with
+	a warning message that indicates the source of the device
+	number and that output might be incomplete as a consequence of
+	the warnings.
+
+	Some system mount tables -- e.g., Linux /proc/mounts -- don't
+	have a dev=xxx option.  In that case, and provided lsof for the
+	dialect supports them, you can use the +m option to create a
+	mount table supplement file and the "+m m" option to use it.
+
+	First check the lsof -h (help) output to see if the +m and
+	"+m m" options are supported.  If they are, use +m to create a
+	mount table supplement file when all mounted file systems are
+	accessible.  Use "+m m" later to make the supplement available
+	when some mounted file systems might not be available.
+
+	Here's an example that creates a mount supplement file in
+	$HOME/mnt-sup and later makes it available to lsof.
+
+	    $ rm -f $HOME/mnt-sup
+	    $ lsof +m > $HOME/mnt-sup
+	    ...
+	    $ lsof +m $HOME/mnt-sup <other lsof options>
+
+	If lsof has to get the device number from the supplement, it
+	will issue an informative warning message.  The warning can be
+	suppressed with lsof's -w option.
+
+	Caution!  Since the mount table supplement file is static, it
+	is its supplier's responsibility to update it as file system
+	mounts change.
+
+	For more information, consult the lsof man page.  The
+	"ALTERNATE DEVICE NUMBERS" section has useful information on
+	how lsof acquires device numbers when stat(2) or lstat(2)
+	fail.
+
+3.46	Why won't lsof find open files on over-mounted file systems?
+
+	When a file system, /xyz for example, is mounted on the same
+	mount point as another file system, /abc for example, running
+	lsof with an argument of the path of the first file system's
+	mount point -- the over-mounted one, /abc -- probably will not
+	reveal any files open on /abc.
+
+	That's because lsof looks for open files on a file system by
+	looking for files with the file system's device number.  The
+	two file systems usually have different device numbers and lsof
+	determines the device number search key from the supplied name
+	of the second file system.
+
+	A general work-around exists only for Linux.  On that UNIX
+	dialect, when you know the over-mounted file system's mount
+	point path, you can ask lsof to report on all open files and
+	grep that output for the path of the over-mounted file system
+	mount point.
+
+3.47	What can be done when lsof reports no more space?
+
+	Many lsof methods cache information in memory, using the
+	dialects malloc() library function.  When malloc() can't
+	allocate the requested amount of memory, lsof exits with
+	warning messages similar to this AIX message:
+
+	    lsof: no more dev-ch space at pid 2257750: 0x82a8e600
+
+	Lsof then exits immediately and produces no more output.
+
+	A possible work-around is to increase the memory foot print
+	of the shell that runs lsof.  That is often done with the
+	ulimit(1) shell command.
+
+3.48	What if the lsof build encounters ar and ld problems?
+
+	The lsof main and library Makefiles use the library archiver,
+	ar, and the system loader, ld, applications.  Improperly
+	located, installed or configured versions of them may cause the
+	lsof build to encounter errors with them.
+
+	The application producing the error should identify itself in
+	its error messages.
+
+	The first thing to check the path of the application that is
+	being used.  Try `which ar` or `which ld` to see if perhaps the
+	PATH used during the build might be causing the wrong archiver
+	or loader to be used.
+
+	If the problem is with the use of the wrong archiver, and it's
+	not possible to correct the PATH to it, try using the LSOF_AR
+	environment variable to specify the path to and arguments for
+	the correct archiver.  See 00XCONFIG for more information and
+	note that LSOF_AR must specify the path to the archive
+	application and the arguments for it, less the terminating
+	library and module name arguments.
+
+	If the problem is with the loader, there is no lsof work-
+	around.  That's because lsof calls the loader via the C
+	compiler, so the problem must be fixed at the compiler (system)
+	level.
+
+3.49	Why does lsof -i report an open socket file for a process, but
+	lsof -p on that process' ID report nothing?
+
+	The lsof in use was probably built with the HASSECURITY and
+	HASNOSOCKSECURITY options and the process in question does not
+	belong to the user of lsof.
+
+	The HASSECURITY option limits lsof output to processes owned
+	by the user invoking lsof and the HASNOSOCKSECURITY option
+	weakens that slightly to allow output of open socket file
+	information for all processes.
+
+	For example, if process PID 12345 is owned by some user other
+	than the one invoking lsof, and lsof has been compiled with the
+	HASSECURITY and HASNOSOCKSECURITY options, the following lsof
+	command will display the open socket files of process 12345:
+
+		$ lsof -p 12345 -a -i
+
+	This security restriction is described in the lsof(8) manual
+	page.
+
+
+4.0	AIX Problems
+
+4.1	What is the Stale Segment ID bug and why is -X needed?
+
+	Kevin Ruderman reports that he has been informed by IBM
+	that processes using the AIX 3.2.x, 4.1[.12345]], 4.2[.1],
+	and 4.3.x kernel's readx() function can cause other AIX
+	processes to hang because of what appears to be file system
+	corruption.
+
+	This failure, known as the Stale Segment ID bug, is caused
+	by an error in the AIX kernel's journaled segment memory
+	handler that causes the kernel's dir_search() function
+	erroneously to believe directory entries contain zeroes.
+	The process using the readx() call need not be doing anything
+	wrong.  Usually the system must be under such heavy load
+	that the segment ID being used in the readx() call has been
+	freed and then reallocated to another process since it was
+	obtained from kernel memory.
+
+	Lsof uses the readx() function to access library entry
+	structures, based on the segment ID it finds in the proc
+	structure of a process.  Since IBM probably will never fix
+	the kernel bug, I've added an AIX-specific option to lsof
+	that controls its use of the readx() function.
+	
+	By default lsof readx() use is disabled; specifying the
+	``-X'' option enables readx() use.
+
+	If you want to change the default readx() behavior of AIX
+	lsof, change the HASXOPT, HASXOPT_ROOT, and HASXOPT_VALUE
+	definitions in dialects/aix/machine.h.  You can also use
+	these definitions to enable or disable readx() -- consult
+	the comments in machine.h.  You may want to disable readx()
+	use permanently if you plan to make lsof publicly executable.
+
+	When HASXOPT_ROOT is defined, lsof will restrict use of
+	the -X option to processes whose real UID is root; if
+	HASXOPT_ROOT isn't defined, any user may specify the -X
+	option.  The Customize script offers the option to change
+	HASXOPT_ROOT when HASXOPT is defined and HASXOPT_ROOT is
+	named in any dialect's machine.h header file.
+
+	I have never seen lsof cause a problem with its use of
+	readx(), but I believe there is some chance it could, given
+	the right circumstances.
+
+4.1.1	Stale Segment ID APAR
+
+	Here are the details of the Stale Segment ID bug and IBM's
+	response, provided by Kevin Ruderman.
+
+	AIX V3
+	  APAR=ix49183
+	      user process hangs forever in kernel due to file
+	      system corruption
+	  STAT=closed prs  TID=tx2527 ISEV=2 SEV=2
+	       (A "closed prs" is one closed with a Permanent
+	       ReStriction.)
+	  RCOMP=575603001 aix v3 for rs/6 RREL=r320
+
+	AIX V4  (internal defect, no apar #)
+	  prefix        p
+	  name          175671
+	  abstract      KERMP: loop for ever in dir_search()
+
+	Problem description:
+
+	1. Some user application -- e.g., lsof -- gets the segment
+	   ID (SID) for the process private segment of a target
+	   process from the process table.
+
+	2. The target process exits, deleting the process private
+	   segment.
+
+	3. The SID is reallocated for use as a persistent segment.
+
+	4. The user application runs again and tries to read the
+	   user area structure from /dev/mem, using the SID it read
+	   from the process table.
+
+	5. The loads done by the driver for /dev/mem cause faults
+	   in the directory; new blocks are allocated; the size
+	   changed; and zero pages created.
+
+	6. The next application that looks for a file in the affected
+	   directory hangs in the kernel's dir_search() function
+	   because of the zero pages.  This occurs because the
+	   kernel's dir_search() function loops through the variable
+	   length entries one at a time, moving from one to the
+	   next by adding the length of the current entry to its
+	   address to get the address of the next entry. This
+	   process should end when the current pointer passes the
+	   end of the known directory length.
+
+	   However, while the directory length has increased, the
+	   entry length data has not, so when dir_search() reaches
+	   the zero pages, it loops forever, adding a length of
+	   zero to the current pointer, never passing the end of
+	   the directory length.  The application process is hung;
+	   it can't be killed or stopped.
+
+	IBM closed the problem with a PRS code (Permanent ReStriction)
+	under AIX Version 3 and had targeted a fix for AIX 4.2.  They
+	have recently (I became aware of it September 10, 1996)
+	cancelled the defect report altogether and have indicated they
+	are not going to fix the defect.
+
+4.2	Gcc Work-around for AIX 4.1x
+
+	When gcc is used to compile lsof for AIX 4.1x, it doesn't
+	align one element of the user structure correctly.  Xlc
+	sees the U_irss element as a type "long long" and aligns
+	it on an 8 byte boundary.  That's because the default mode
+	of xlc is -qlonglong; when -qlonglong is enabled, the
+	_LONG_LONG symbol is also defined.
+
+	Gcc sees U_irss as a two element array of type long, because
+	_LONG_LONG isn't defined.  Hence gcc aligns the U_irss
+	element array on a 4 byte boundary, rather than an 8 byte
+	one, making the gcc incantation of the user structure 4
+	bytes shorter than xlc's.
+
+	When the length of gcc's user structure is supplied as
+	argument 4 to the undocumented getuser() function of the
+	AIX kernel, getuser() rejects it as an incorrect size and
+	returns EINVAL.
+
+	Lsof has a work-around for this problem.  It involves a
+	special test in the Configure script when the "aixgcc"
+	Configure abbreviation is used -- e.g.,
+
+		$ Configure -n aixgcc
+
+	The test is to compile a small program with gcc and check
+	the alignment of U_irss.  If it's not aligned on an 8 byte
+	boundary, the Configure script makes a special copy of
+	<sys/user.h> in ./dialects/aix/aix<AIX_version> whose
+	U_irss will align properly, and generates compile time
+	options to use it.
+
+	While I have tested this work-around only with 4.1.4, it
+	should work with earlier versions of AIX 4.1.  It does not
+	work for AIX 4.2; a different work-around is employed there.
+	(See the next section.)
+
+	If you want to use this technique to compile other AIX
+	4.1x programs with gcc for using getuser(), check the
+	Configure script.
+
+	Stuart D. Gathman identified this gcc AIX alignment problem.
+
+4.3	Gcc and AIX 4.2[.1]
+
+	Alignment problems with gcc and AIX 4.2[.1] inside the user
+	structure are more severe, because there are some new 64
+	bit types in AIX that gcc doesn't yet (as of 2.7.x) support.
+	The <sys/user.h> U_irss element problem, discussed in 4.3
+	above, doesn't exist in 4.2[.1].
+
+	The AIX lsof machine.h header file has a work-around,
+	provided by Henry Grebler, that bypasses gcc alignment
+	problems.  Later versions of gcc (e.g., 2.8.x) will probably
+	bypass the problems as well.
+
+4.4	Why won't lsof's Configure allow the use of gcc for AIX
+	below 4.1?
+
+	Gcc can't reliably be used to compile lsof for AIX versions
+	below AIX 4.1 because of possible kernel structure element
+	alignment differences between it and xlc.
+
+4.5	What is an AIX SMT file type?
+
+	When you run AIX X clients with the DISPLAY environment
+	variable set to ``:0.0'' they communicate with the AIX X
+	server via files whose kernel file structure has an undefined
+	type (f_type == 0xf) -- at least there's no definition for
+	it in <sys/file.h>.
+
+	These are Shared Memory Transport (SMT) sockets, an artifact
+	of AIXWindows, designed for more efficient data transfers
+	between the X server and its clients.
+
+	Henry Grebler and David J. Wilson alerted me to the existence
+	of these files.  Mike Feldman and others helped me identify
+	them as SMT sockets.
+
+	The curious reader can find more about SMT sockets in
+	/usr/lpp/X11/README.SMT.
+
+4.6	Why does AIX lsof start so slowly?
+
+	When AIX lsof starts it compares the running kernel's
+	identity to the one for which it was built, using
+	/usr/bin/oslevel.  That comparison can sometimes take a
+	long time to complete, depending on the system's maintenance
+	level and how recently it was examined with oslevel.
+
+	AIX revisions 4.67 and above for AIX 5 and above don't use
+	oslevel to determine the kernel identity.  They use uname(2)
+	instead, and it is much faster.
+
+	You can skip the oslevel test by suppressing warning messages
+	with lsof's -w option.  Doing that carries with it the risk
+	of missing other warning messages, however.
+
+	You can also disable the kernel identity check by disabling
+	the definition of the HASKERNIDCK symbol by editing AIX
+	machine.h header file or by using the Customize script to
+	disable it.
+
+	See the "Why does lsof warn "compiled for x ... y; this is
+	z.?" section for more information.
+
+4.7	Why does exec complain it can't find libc.a[shr.o]?
+
+	When you try to execute lsof you may get this complaint:
+
+	    exec(): 0509-036 Cannot load program ./lsof because of
+		        the following errors:
+		    0509-022 Cannot load library libc.a[shr.o].
+		    0509-026 System error: A file or directory in
+			the path name does not exist.
+
+	This is probably the result of making lsof when the LIBPATH
+	environment variable contained a directory path that doesn't
+	contain libc.a.  You can see what LIBPATH contained when
+	lsof was made by using the dump application on lsof.  For
+	example, if LIBPATH contained /foo/bar when lsof was made,
+	you will see this (partial) dump output:
+
+	    $ dump -H lsof
+	    ...
+			***Import File Strings***
+	    INDEX  PATH                          BASE         ...
+	    0      /foo/bar
+
+	To correct the problem, revisit the lsof source directory
+	and remake lsof this way:
+
+	    $ unset LIBPATH; make		(sh or ksh)
+	or
+	    % unsetenv LIBPATH; make		(csh or tcsh)
+
+4.8	What does lsof mean when it says, "no PCB, CANTSENDMORE,
+	CANTRCVMORE" in a socket file's NAME column?
+
+	When an AIX application calls shutdown(2) on an open socket
+	file, but hasn't called close(2) on the file, the file will
+	remain visible to lsof as an open socket file without any
+	extended protocol information.
+
+	Lsof reports that state in the NAME column by saying that
+	there is "no PCB" (Protocol Control Block) for the protocol
+	(e.g., TCP in the NODE column).  If the open socket file
+	has the state variables SO_CANTSENDMORE and SO_CANTRCVMORE
+	set -- i.e., from the shutdown(2) call -- lsof reports them
+	with the CANTSENDMORE and CANTRCVMORE notes in the NAME
+	column.
+
+4.9	When the -X option is used on AIX 4.3.3, why does lsof disable
+	it, saying "WARNING: user struct mismatch; -X option disabled?"
+
+	The -X option causes lsof to read the loader information
+	of the user structure from virtual memory via the readx()
+	system call.  It does that with the user structure definition
+	from <sys/user.h> that was compiled into the lsof executable.
+
+	On AIX 4.3.3 there are two different user structure
+	definitions in two separate <sys/user.h> header files,
+	distributed at different times by IBM.  If lsof was compiled
+	with one and the kernel on which lsof is being run was
+	compiled with the other, lsof normally won't get correct
+	loader information when it calls readx().
+
+	In an attempt to compensate for that difference, lsof makes
+	an independent check of the loader information by getting
+	the user structure's open file count via readx() and
+	comparing it to the open file count obtained independently
+	via getprocs().  When the two counts don't match, lsof
+	tries to read the count (and re-read the loader information)
+	with two offsets, based on observed differences between
+	the two user structures.
+
+	When one of the three attempts produces a correct open file
+	count, lsof uses its corresponding offset on subsequent
+	readings of the loader information.
+
+	When none of the three attempts produces a correct open
+	file count, lsof issues the WARNING message and disables
+	-X processing.
+
+	To eliminate this problem, obtain an lsof binary that
+	matches the kernel of the AIX 4.3.3 system where you want
+	to run lsof.  Compiling lsof on the target system is the
+	preferred way to get a matching binary.
+
+4.10	Why doesn't the -X option work on my AIX 5L or 5.[123] system?
+
+	If your AIX 5L or 5.[123] system uses the ia64 architecture,
+	lsof needs setuid-root permission to be able to do the
+	processing that -X requires.
+
+	Check the output of `uname -a` to determine the architecture
+	type.
+
+	The work-around is to give lsof setuid-root permission.
+
+4.11	Why doesn't /usr/bin/oslevel report the correct AIX version?
+
+	The oslevel man page says, "The oslevel command reports
+	the level of the operating system using a subset of all
+	filesets installed on your system."
+
+	You can see which fileset is below the expected level with
+	oslevel's -l option.  For example, if you believe your
+	system is at AIX level 4.3.3, but oslevel reports 4.3.2,
+	use this oslevel command to find the filesets below 4.3.3:
+
+	    $ /usr/bin/oslevel -l 4.3.3.0
+
+	If you don't know what level argument to supply to oslevel's
+	-l option, use oslevel's -q option first.
+
+4.11.1	Why doesn't /usr/bin/oslevel report the correct AIX version
+	on AIX 5.1?
+
+	The subset list for oslevel on AIX 5.1 seems to include at
+	least two filesets, xlsmp.msg.en_US.rte and xlsmp.rte, that
+	do not install from AIX 5.1 media with a 5.1.0.0 level.
+	Hence, oslevel reports 5.0.0.0 instead of the expected
+	5.1.0.0.
+
+	If either xlsmp.msg.en_US.rte or xlsmp.rte is installed,
+	lsof's Configure script and run-time tests will identify
+	the AIX version incorrectly.  The run-time test will
+	issue a complaint message of this form:
+
+	    lsof: WARNING: compiled for AIX version xxx; this is yyy.
+
+	You can correct the Configure test by pre-defining the
+	oslevel value, setting the correct value in the LSOF_VSTR
+	environment variable before running the Configure script
+	-- e.g., to pre-define AIX 5.1 when using ksh, do this:
+
+	    $ LSOF_VSTR=5.1.0.0 Configure -n aix
+
+	You can't affect oslevel output without uninstalling
+	xlsmp.msg.en_US.rte and xlsmp.rte.  If you can't do that,
+	you'll have to put up with the run-time complaint.
+
+4.12    Why does lsof for AIX 5.1 or above Power architecture
+	complain about kernel bit size?
+
+	When you run an lsof binary on an AIX 5.1 or above Power
+	system, it might complain:
+
+	    lsof: FATAL: compiled for a 32 bit kernel.
+		  The bit size of this kernel is 64.
+	or
+	    exec: 0509-036 Cannot load program ./lsof because of
+			   the following errors:
+	          0509-032 Cannot run a 64-bit program on a 32-bit
+			   machine.
+
+	Starting at lsof revision 4.61, lsof binaries for Power
+	architecture systems running AIX 5.1 or above are closely
+	tied to the kernel bit size.  Lsof must do that so it can
+	read and understand kernel structures.
+
+	Lsof's Configure script tunes the lsof configuration so
+	that the binary built in the make(1) step is adjusted to
+	the kernel bit size.
+
+	An lsof binary knows the bit size for which it was constructed,
+	tests the bit size of the kernel under which it is running,
+	and objects if the two sizes don't match.  To see the bit
+	size for which lsof was constructed, run it with its -v
+	option and look for these lines in the output:
+
+	    configuration info: 32 bit kernel
+	 or
+	    configuration info: 64 bit kernel
+
+	(Note: these lines will appear only in -v output for AIX
+	5.1 and above lsof binaries, built for Power architecture.)
+
+	You can see the kernel bit size test method in the aix
+	stanza of the lsof Configure script and in the get_kernel_access()
+	function of the lsof .../dialects/aix/dproc.c source file.
+
+	There is more information on pre-defining the kernel bit
+	size when building lsof in Configure, 00PORTING, and
+	00XCONFIG.
+
+	The only work-around is to use an lsof binary built to
+	match the running kernel bit size.
+
+4.13	What can't gcc be used to compile lsof on the ia64 architecture
+	for AIX 5 and above?
+
+	Gcc can't be used to compile lsof on the ia64 architecture
+	for AIX 5 and above because I haven't had access to a system
+	that has a working gcc compiler.  The gcc compiler on my
+	one and only ia64 AIX 5.1 test system, provided by IBM,
+	didn't work at all.
+
+4.14	Why does lsof get a segmentation fault when compiled with gcc
+	for a 64 bit Power architecture AIX 5.1 kernel?
+
+	When lsof is configured with the lsof "aixgcc" Configure
+	abbreviation, the resulting lsof executable may cause a
+	segmentation violation when it is run.  I've observed this
+	with gcc version 2.9-aix43-010414-7.
+
+	As far as I have been able to tell, the segmentation fault
+	is the result of a gcc compilation, loading, or library
+	error.  Watching lsof run with gcc's companion debugger,
+	gdb, shows no error in the lsof source code that might
+	explain the fault.
+
+	The only work-around I know is to use the IBM C compiler
+	in place of gcc -- i.e., use the "aix" lsof Configure
+	abbreviation.
+
+4.15	Why does lsof ignore AFS on my AIX system?
+
+	The lsof Configure script quits on AIX when AFS is present,
+	the AIX version is greater than 4.3.3.0 or the AFS version
+	is greater than 3.5.  That's because I have no test systems
+	available for those AIX and AFS version combinations.
+
+	When the lsof Configure script detects an AIX and AFS
+	version combination that is unsupported, it will report:
+
+	  !!!FATAL: Lsof does not support AFS on this combination of
+		    AIX and AFS versions.  To disable AFS, set the
+		    value of the AIX_HAS_AFS environment variable to
+		    "no".
+
+	The only work-around is to set the AIX_HAS_AFS environment
+	variable as explained in the error message:
+
+	    $ AIX_HAS_NSF=no; export AIX_HAS_NFS
+	    $ ./Configure -n aix
+
+4.16	Why does lsof report "system paging space is low" and exit?
+
+	When AIX paging space runs low, the AIX kernel sends a SIGDANGER
+	signal to processes, warning them that they should reduce their
+	memory usage.
+
+	When lsof receives that signal, it issues the following fatal
+	error message and exits:
+
+	    lsof: FATAL: system paging space is low.
+
+	A possible work-around is to limit the amount of information
+	lsof must cache in its process memory with the "-c", "-g", "-l"
+	and "-p" options.
+
+	Also see the answer to the "What can be done when lsof reports
+	no more space?" question.
+
+4.17    Why does lsof have a compilation problem on AIX 5.3 above
+	maintenance level 1?
+
+	On some AIX 5.3 systems with maintenance levels 2 and higher
+	installed, lsof 4.77 and below may not compile properly.  The
+	compiler complains the snapshotObject structure definition,
+	needed by <j2/j2_inode.h>, is missing.
+
+	That problem is fixed in the 4.78 revision.
+
+
+5.0	Apple Darwin Problems
+
+5.1	What do /dev/kmem-based and libproc-based mean?
+
+	Lsof for Apple Darwin currently uses /dev/kmem to read kernel
+	data structures from which it gathers and reports open file
+	information.  That version of lsof is called /dev/kmem-based
+	lsof.
+
+	At an upcoming release lsof will use a library called libproc
+	to obtain information about open files.  That version of lsof
+	wil be called libproc-based lsof.
+
+	The /dev/kmem-based lsof sources may be found in the kmem
+	subdirectory of the dialects/darwin branch of the lsof source
+	tree.  When the supporting version of Apple Darwin is released,
+	the libproc-based lsof sources will be found in
+	.../dialects/darwin/libproc.
+
+5.2	/dev/kmem-based Apple Darwin Questions
+
+5.2.1	Why does Configure ask for a path to the Darwin XNU kernel
+	header files?
+
+	When lsof was ported to Apple Darwin by Allan Nathanson at
+	revision 4.53, some kernel header files needed by lsof
+	weren't being exported by the developers.  (That's still
+	true at lsof revision 4.76.)
+
+	At first a shell script that Allan provided would get the
+	missing header files by checking them out from the CVS
+	root.  Although the script was updated from time to time,
+	eventually the re-organization of Darwin sources has made
+	it impossible to update the script to do an automatic
+	download of the missing header files.
+
+	At lsof revision 4.69 and above it is necessary for the Darwin
+	lsof builder to download the Darwin XNU kernel headers before
+	attempting to build lsof.  The download my be done via a web
+	browser, starting at this URL:
+
+	    http://www.opensource.apple.com/darwinsource/index.html
+
+	Once there, select the link to the Mac OS X version that
+	matches the one on the system where lsof is to be built.
+
+	Follow that link's "[ Source ]" link.  Once there, select the
+	tar.gz link of the xnu* entry near the bottom of the page.
+	That entry should have a name that matches the xnu* name shown
+	by `uname -a` -- e.g., if uname reports:
+
+	    $ uname -a
+	    ... root:xnu/xnu-517.7.21 ...
+
+	Then the appropriate xnu* entry is xnu-517.7.21.  Clicking
+	its link should lead to an "Apple Open Source" page requesting
+	an Apple ID and password.
+
+	Enter them if they're available.  If an Apple ID and password
+	are not available, get them by following the instructions on
+	the page -- i.e., follow the signin.apple.com link.
+
+	Once a valid Apple ID and its password have been entered,
+	the download will begin.  Select the saving of the downloaded
+	xnu*.tar.gz file in an appropriate place on the Mac OS X
+	system.
+
+	Once the download completes, install it.  Use gunzip to
+	decompress the download and tar to extract the archive -- e.g.,
+
+	    $ gunzip -c xnu-517.7.21.tar.gz | tar xf -
+	
+	Remember the absolute path to the extracted archive.  That is
+	its installed place.  E.g., if the xnu-517.7.21.tar archive was
+	extracted to the lsof builder's home directory, its full
+	installation path will be something like:
+
+	    ~/xnu-517.7.21
+
+	Now run the lsof Configure script.  When it asks for the path
+	to the installed Darwin XNU kernel header files, supply the
+	path to the gunzip'd and extracted xnu* archive -- e.g.,
+	~/xnu-517.7.21.
+
+	The path to the Darwin XNU kernel headers may also be
+	supplied to the Configure script in the DARWIN_XNUDIR
+	environment variable, eliminating the need to enter it
+	interactively -- e.g.,
+
+	    $ DARWIN_XNUDIR=~/xnu-344.49 ./Configure -n darwin
+
+5.2.1.1	Why does Configure complain that Darwin XNU kernel header
+	files are missing?
+
+	These are some reasons why the lsof Configure script might
+	claim that Darwin XNU header files are missing:
+
+	    * The wrong path to them was specified.
+
+	    * The files and directories in the path are not readable
+	      and searchable -- i.e., check the modes and ownerships.
+
+	    * The downloaded archive doesn't match the Mac OS X
+	      version of the system.
+
+	If in doubt, revisit the Darwin XNU kernel header file
+	download instructions in the answer to the question "Why
+	does Configure ask for a path to the Darwin XNU kernel
+	header files?"
+
+	If Configure still can't find Darwin XNU kernel header
+	files, contact me via e-mail at <abe@purdue.edu> for help.
+	Make sure "lsof" appears in the "Subject:" line so my e-mail
+	filter won't classify your letter as Spam.
+
+5.2.2	Why doesn't Apple Darwin lsof report text file information?
+
+	At the first port of lsof to Apple Darwin, revision 4.53,
+	insufficient information was available -- logic and header
+	files -- to permit the installation of VM space scanning
+	for text files.  As of lsof 4.70 it is sill not available.
+
+	Text file support will be added to Apple Darwin lsof after
+	the necessary information becomes available.
+
+5.2.3	Why doesn't Apple Darwin lsof support IPv6?
+
+	At the first port of lsof to Apple Darwin, revision 4.53,
+	Apple Darwin lacked IPv6 support.  IPv6 became available
+	in Apple Darwin version 1.5 and support for it was added
+	to lsof then.
+
+5.2.4	Why does lsof complain about a mismatch between the release
+	for which lsof was compiled and the booted Mac OS X release?
+
+	When lsof is started on the "Gold Master" Darwin release
+	(aka Mac OS X), it complains:
+
+	    lsof: compiled for 1.0 release; this is 1.3.2.
+
+	This happens because the lsof binary released with Mac OS
+	X was built on a system whose release number (1.0) doesn't
+	match that of the released system -- usually 1.3.x  Lsof
+	makes this check because UNIX dialect OS changes are often
+	accompanied by header file changes that affect lsof.
+
+	In this specific case, this error can be ignored.  If you
+	don't want to do that, get the lsof distribution and build
+	lsof so its built-on and running-on Mac OS X release numbers
+	match.
+
+5.2.5	Why does lsof for Apple Darwin 8 and higher report
+	"stat(...): ..." in the NAME column?
+
+	Lsof for Apple Darwin 8 may report messages like these in the
+	NAME column:
+
+	    stat(/private/var/run/asl_prune): No such file or directory
+	 or
+	    stat(/private/var/db/netinfo/local.nidb/Config): Permission denied
+
+	Those messages indicate that lsof was unable to collect open
+	file information for the paths enclosed in "stat(...)" with the
+	stat(2) function, because the function encountered the reported
+	error.
+
+	A work-around for the "Permission denied" error is to run lsof
+	with elevated privileges -- e.g., when logged on as the super
+	user.
+
+	If the stat(2) error message is "No such file or directory",
+	the file probably has been unlinked (removed) and there is no
+	lsof work-around.
+
+5.2.6	What are the limitations of Apple Darwin lsof link count
+	reporting?
+
+	Lsof for Apple Darwin cannot report link count information
+	reliably.
+	
+	For Apple Darwin below 8 link count information is not always
+	available in the kernel node structures available to lsof.
+	When link count information is available, however, it includes
+	link counts of zero.  Thus, using lsof's +L1 option may result
+	in the finding of some files whose link counts are zero.
+
+	Lsof can report only some link count information for Apple
+	Darwin 8 and above.  Link count information is only available
+	for files where lsof can assemble the full file path and has
+	permission to apply stat(2) to it.  (See the answer to the "Why
+	does lsof for Apple Darwin 8 and higher report "stat(...): ..."
+	in the NAME column?" question for more information on stat(2)
+	failures.)
+
+	Apple Darwin 8 and above files that have been unlinked and thus
+	have a link count of zero cannot be found by stat(2) -- i.e.,
+	stat(2) returns a "No such file or directory" error.  As a
+	result lsof never displays link counts of zero and the use of
+	lsof's +L1 option to find them always fails.
+
+5.2.7	Why does Apple Darwin report process group IDs incorrectly?"
+
+	The kmem version of lsof for Apple Darwin does not report
+	process group IDs correctly when requested to do so with its
+	``-g'' option.  This is a bug that surfaced after the libproc
+	version was released and access to kmem test systems has
+	prevented patching the bug.
+
+	If you are using the kmem version and would like a fix for this
+	problem, please send e-mail to me <abe@purdue.edu>.  Make sure
+	"lsof" appears in the "Subject:" line so my e-mail filter won't
+	classify your letter as Spam.
+
+5.3	Libproc-based Apple Darwin Questions
+
+	
+6.0	BSD/OS BSDI Problems
+
+6.0.5	Statement of deprecation
+
+	As of lsof revision 4.76 support for BSDI BSD/OS has been
+	dropped.  The 4.76 distribution of lsof for BSDI BSD/OS may be
+	found on lsof.itap.purdue.edu in pub/tools/unix/lsof/OLD/src.
+
+
+7.0	DEC OSF/1, Digital UNIX, and Tru64 UNIX Problems
+
+7.1	Why does lsof complain about non-existent /dev/fd entries?
+
+	When you run lsof for Digital UNIX 3.2, lsof may complain:
+
+	    lsof: can't lstat /dev/fd/xxx: No such file or directory
+	    lsof: can't lstat /dev/fd/yyy: No such file or directory
+
+	(Or it may warn about other missing /dev/fd paths.)  When
+	you do an ``ls /dev/fd'' none of the missing paths are listed.
+
+	This is caused by a bug in the DEC library function
+	getdirentries().  For some reason, when /dev/fd is a file
+	system mount point, getdirentries() returns an incorrect
+	size for it to readdir().  (Lsof calls readdir() in its
+	ddev.c readdev() function.)  Because of the incorrect size,
+	readdir() goes past the end of the /dev/fd directory buffer,
+	encounters random paths and returns them to lsof.  Lsof
+	then attempts to lstat(2) the random paths, gets error
+	replies from lstat(2), and complains about the paths.
+
+	Duncan McEwan discovered this error and has reported it to
+	DEC.  Duncan also supplied an alternate readdir() function
+	as a work-around.  I've incorporated his readdir() in
+	dialects/osf/ddev.c (as the static ReadDir() function) with
+	some slight modifications, and enabled its use when the
+	USELOCALREADDIR symbol is defined.
+
+	The Configure script defines USELOCALREADDIR for Digital
+	UNIX version and 3.2.  If you don't want to use Duncan's
+	local readdir() function, edit the Makefile and remove
+	-DUSELOCALREADDIR from the CFGF string.  When DEC releases
+	a corrected getdirentries() function, I'll modify the
+	Configure script to stop defining USELOCALREADDIR.
+
+7.2	Why does the Digital UNIX V3.2 ld complain about Ots* symbols?
+
+	When you compile lsof on your Digital UNIX V3.2 system, ld
+	may complain:
+
+	    ld:
+	    Unresolved:
+	    knlist
+	    _OtsRemainder32Unsigned
+	    _OtsDivide64Unsigned
+	    _OtsRemainder64Unsigned
+	    _OtsDivide32Unsigned
+	    _OtsMove
+	    _OtsDivide32
+	    _OtsRemainder32
+	    *** Exit 1
+
+	Chris Eleveld reports this happens on Digital UNIX V3.2
+	systems after the Fortran compiler has been installed.
+
+	The best work-around seems to be to remove -lmld from the
+	CFGL string in the Makefile produced by Configure -- i.e.,
+	change:
+
+	    CFGL=    -lmld
+	to
+	    CFGL=
+
+	According to the V3.2 man page for nlist(3), this shouldn't
+	work, but my testing shows that it does.  Although I haven't
+	been able to test this second work-around, you might try
+	adding -lots to CFGL, rather than removing -lmld -- i.e.,
+	change:
+
+	    CFGL=    -lmld
+	to
+	    CFGL=    -lmld -lots
+
+	WARNING: my testing also shows that the V2.0 nlist(3) man
+	page means what it says when it calls for -lmld -- lsof
+	loaded without -mld under V2.0 can't locate the proc
+	(process) table address.
+
+	    DON'T REMOVE -lmld FROM THE DIGITAL UNIX V2.0 MAKEFILE.
+
+	If you run into this problem, please let me know what
+	problem you encountered and how you solved it.
+
+7.3	Why can't lsof locate named pipes (FIFOs) under V3.2?
+
+	While lsof for V3.2 can report on named pipes (FIFOs), it
+	can't find them by name.  That appears to happen because
+	of the way the V3.2 kernel lstat(2) function reports named
+	pipe device numbers.
+
+	The V3.2 kernel reports the device number as 0xfffffff,
+	while the kernel structures for named pipes that lsof
+	examines contain the device number of the file system on
+	which the named pipe resides.
+
+	Consequently, lsof can't match the device and inode number
+	pair it receives from applying lstat(2) to the named pipe
+	with any device and inode number pair it finds when scanning
+	kernel structures.
+
+	I don't have a work-around.  You can, of course, ask for
+	full lsof output and use a post-processing filer (e.g.,
+	grep) to locate the named pipe of interest.
+
+	This problem doesn't exist under V2.0.
+
+7.4	Why does lsof use the wrong configuration header files?
+	For example, why can't the lsof compilation find cpus.h?
+
+	DEC OSF/1, Digital UNIX, and Tru64 UNIX configuration header
+	files describe the hardware and software environment for
+	which your kernel boot file was constructed.  For example,
+	/sys/<name>/cpus.h defines the number of CPUs in its NCPUS
+	#define.
+
+	Lsof searches for the configuration header file subdirectory
+	in /sys (/usr/sys for Digital UNIX version 4.0 and Tru64
+	UNIX) by converting the first host name component to capital
+	letters -- e.g., TOMIS is derived from tomis.bio.purdue.edu.
+	If that subdirectory exists, lsof uses header files from
+	it.  (Configure reports what subdirectory is being used.)
+
+	If Configure doesn't find a host-name derived subdirectory,
+	it prompts you for the entry of a subdirectory name.  If
+	you can't find one, quit Configure and run the kernel
+	generation process to create a proper configuration sub-
+	directory.  If you don't identify a proper configuration
+	subdirectory and you try to compile lsof, the compiler will
+	complain about missing header files -- e.g., a missing
+	cpus.h.
+
+	Once you have located or generated a proper configuration
+	subdirectory, rerun Configure.  If you have generated a
+	configuration subdirectory whose name is derived from the
+	host name, Configure will find and use it.  If not, you
+	will have to specify its name to Configure.
+
+7.5	Why does lsof indicate incomplete paths with " -- " for Tru64
+	UNIX 5.1 files?
+
+	When lsof can't find a component of a path in the kernel's
+	name cache (aka DNLC), or can't determine that the left-most
+	component has as its parent the file system root, it uses
+	an "incomplete path" notation.  That notation begins with
+	the file system root name, followed by " -- ", followed by
+	the consecutive path name components lsof was able to find
+	in the DNLC -- e.g., "/ -- init".
+
+	Because the DNLC was significantly redesigned in Tru64 UNIX
+	5.1, lsof's handling of the cache had to be completely
+	redone.  As part of the DNLC redesign a name cache entry
+	parameter lsof formerly used to locate the file system root
+	of a path was removed.  With help from Chang Song I've been
+	able to implement an alternate method for detecting the
+	root of these file system types:  AdvFS (MSFS), CDFS, DVDFS,
+	FDFS, NFS, NFS3, and UFS.
+
+	When lsof doesn't know how to identify the root for a file
+	system type, it will resort to the " -- " incomplete path
+	notation.
+
+7.6	Why doesn't lsof report link count, node number, and size
+	for some Tru64 5.x CFS files?
+
+	Lsof reports link count, node number, and size for open
+	CFS files as recorded in their kernel node structure's
+	cached attributes.  Sometimes not all attributes are cached
+	on the system where lsof runs, so lsof cannot report them.
+
+7.7     Why does lsof say it can't read the kernel name list or
+	proc table on Digital UNIX 4.x or Tru64 UNIX?
+
+	By default on Digital UNIX 4 and Tru64 UNIX lsof reads the
+	addresses for kernel symbols with the knlist(3) function.
+	That function can fail, for example, when the kloadsrv
+	daemon isn't running or is malfunctioning.  When that
+	happens, lsof may abort with one of these error messages:
+
+	    lsof: can't read kernel name list from knlist(3): ...
+	  or
+	    lsof: can't read proc table info
+
+	The first message suggests a complete knlist(3) or kloadsrv
+	failure; the second, a partial one.
+
+	If you know the name of the file from which the running
+	system was booted, e.g., /vmunix, you can use lsof's -k
+	option to direct it to read kernel symbol addresses from
+	the name list of that file --
+
+	    $ lsof -k /vmunix ...
+
+	If that works, then knlist(3) is malfunctioning and you
+	need to fix it.
+
+
+8.0	FreeBSD Problems
+
+8.1	Why doesn't lsof report on open kernfs files?
+
+	Lsof doesn't report on open FreeBSD kernfs files because
+	the structures lsof needs aren't defined in the kernfs.h
+	header file in /sys/misc/kernfs.
+
+8.2	Why doesn't lsof work on my FreeBSD system?
+
+	If lsof doesn't work on your FreeBSD system, first make
+	sure you have the latest lsof revision.  See the answer to
+	the "Where do I get lsof?" question for information on how
+	to get the latest lsof revision.
+
+	Once you have gotten the latest lsof revision, Configure
+	and make it.  If Configure fails -- e.g., it complains
+	about an unknown FreeBSD version -- then lsof probably
+	hasn't been ported to your FreeBSD version yet, and there's
+	no need to go any further.  Follow the answer to the "How
+	do I report an lsof bug" to report the Configure complaint
+	to me.
+
+	If you are able to Configure and make lsof, run its test
+	suite.  (See the answer to the "Is there a test suite?"
+	question for more information on how to use lsof's test
+	suite.)
+
+	If lsof still fails, make sure your kernel sources, kernel
+	header files, kernel boot file, standard header files and
+	libraries are synchronized.  They should all be built from the
+	same CVS refresh.  (Don't forget to do a "make buildworld"
+	followed by a "make installworld".)  If they aren't, then the
+	KVM library or lsof may be using kernel structure definitions
+	that don't match the booted kernel; or lsof may fail to compile
+	properly because of header files in /usr/src/sys/sys and
+	/usr/include/sys that don't match.
+
+	If you have synchronized your kernel, header files and
+	libraries, and still can't get lsof to work, follow the
+	steps in the answer to the "How do I report an lsof bug"
+	question to report the problem to me.
+
+8.3	Why doesn't lsof work on the RELEASE version of CURRENT?
+
+	Lsof tracks the CURRENT release of the current leading edge
+	FreeBSD version, because my access to leading edge FreeBSD is
+	limited to FreeBDSD.org reference systems, all running the
+	CURRENT release.
+
+	Sometimes that tracking leads to changes in lsof that won't
+	work on an earlier RELEASE version of the current leading edge
+	version.
+
+	When that happens, please send e-mail to me <abe@purdue.edu>.
+	Make sure "lsof" appears in the "Subject:" line so my e-mail
+	filter won't classify your letter as Spam.
+
+8.4	Why does kvm_open() complain it can't find some file?
+
+	If lsof issues this complaint:
+
+	    lsof: kvm_open(execfile=/boot/kernel/kernel,
+		  corefile=/dev/mem: No such file or directory
+
+	Your FreeBSD system might not have a /dev/mem device.  If
+	not, create one -- e.g., as root do:
+
+	    # mknod /dev/mem c <major> 0
+	    # chmod 440 /dev/mem
+	    # chgrp kmem /dev/mem
+
+	For <major> use /dev/kmem's major device number.
+
+	You may have to run kldload, too -- again as root do:
+
+	    # kldload mem
+
+8.5	FreeBSD ZFS Problems
+
+8.5.1	Why does FreeBSD lsof report "WARNING: no ZFS support has been
+	defined."?
+
+	Lsof issues that message when it detects a file on a ZFS file
+	system, but has not been built with support for ZFS.  Lsof's
+	Configure script detects support can be added for ZFS when it
+	finds this file:
+
+	/usr/src/sys/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_znode.h
+
+	That header file and others in the OpenSolaris files in
+	/usr/src enable lsof to extract information about ZFS files
+	from the kernel structures associated with them.
+
+8.6	Why can't Configure create lsof_owner.h for FreeBSD 6 and above?
+
+	Lsof may report:
+
+	    Creating ./lockf_owner.h from /usr/src/sys/kern/kern_lockf.c
+	    FATAL ERROR: can't read /usr/src/sys/kern/kern_lockf.c
+	    FATAL ERROR: ./lockf_owner.h creation failed (see 00FAQ)
+	or
+	    Creating ./lockf_owner.h from /usr/src/sys/kern/kern_lockf.c
+	    FATAL ERROR: ./lockf_owner.h creation failed (see 00FAQ)
+
+	Those messages mean that lsof's Configure script failed to
+	create a local header file, ./lockf_owner.h, needed to use the
+	new kernel file locking code of some versions of FreeBSD 6 and
+	above.
+
+	The changes that implement that new locking code alter the
+	lockf structure in <sys/lockf.h> and introduce a new structure,
+	lockf_entry, to that header file.  When Configure detects the
+	presence of the lockf_entry definition in <sys/lockf.h>, it
+	tries to construct the local header file, ./lockf_owner.h.
+
+	Configure has to do that  because an unfortunate side effect of
+	the new kernel file locking code is that <sys/lockf.h> doesn't
+	contain the lockf_owner structure definition referenced in its
+	own lockf structure.  Lsof needs to access elements of that
+	lockf_owner structure to determine if a lock belongs to the
+	process that has a file open.
+
+	The missing lockf_owner structure definition is in the kernel
+	source file, typically /usr/src/sys/kern/kern_lockf.c.
+	Configure tries to extract the lockf_owner structure definition
+	from kern_lockf.c into lsof's local header file, ./lockf_owner.h.
+	If Configure can't do that, it reports:
+
+	    FATAL ERROR: ./lockf_owner.h creation failed
+
+	If Configure can't even read kern_lockf.c, it first reports:
+
+	    FATAL ERROR: can't read /usr/src/sys/kern/kern_lockf.c
+
+	The work-around for this problem is to update the FreeBSD
+	kernel /usr/src tree (e.g., do a CVSup or csup) on the system
+	where lsof is to be built and then do a "make buildworld"
+	followed by a "make installworld".
+
+8.6.1	Why are there lockf structure compiler errors for FreeBSD 6.0
+	and higher lsof?
+
+	If, when compiling lsof, the compiler complains with error
+	messages like:
+
+	    dnode.c: In function 'get_lock_state':
+	    dnode.c:113: error: 'struct lockf' has no member named 'lf_flags'
+	    dnode.c:115: error: 'struct lockf' has no member named 'lf_id'
+	    ...
+	    
+	Then lsof is being built on a system that has new kernel file
+	locking code and lsof's Configure script failed to build a
+	local lockf_owner.h header file with a structure definition
+	lsof needs.
+
+	See the "Why can't Configure create lsof_owner.h for FreeBSD 6
+	and above?" section for more information and a work-around.
+
+8.6.2	Why don't /usr/src/sys/sys/lockf.h and /usr/include/sys/lockf.h
+	match?
+
+	This mismatch can cause the errors explained in the answer to
+	the "Why are there lockf structure compiler errors for FreeBSD
+	6.0 and higher lsof?" question.
+
+	If /usr/src/sys/sys/lockf.h has been updated with a CVSup or
+	csup, the new lockf.h won't be propagated to /usr/include/sys
+	until the "make buildworld" and "make installworld" steps have
+	been completed.
+
+8.7	FreeBSD and clang
+
+	As of lsof revision 4.87, lsof may be compiled with clang.
+
+8.7.1	Why does clang complain about VOP_FSYNC?
+
+	There is an error in the Solaris ZFS compatibility vnode.h
+	header file with use of VOP_FSYNC before it is defined.  No
+	work-around is possible that will eliminate the clang
+	compile-time warning message about the invalid declaration of
+	the VOP_FSYNC function.
+
+
+9.0	HP-UX Problems
+
+9.1	What do /dev/kmem-based and PSTAT-based mean?
+
+	Lsof for HP-UX 11.0 and below uses /dev/kmem to read kernel
+	data structures from which it gathers and reports open file
+	information.  That version of lsof is called /dev/kmem-based
+	lsof.
+
+	Starting with HP-UX 10.10, finding definitions for the
+	necessary kernel structures became more difficult as HP no
+	longer distributed header files in /usr/include that defined
+	all kernel structures.  So I started "inventing" structure
+	definitions by using Q4 to display them.
+
+	By HP-UX 11, the process of invention became extremely
+	intensive to support.  Following a patch to the ipc_s
+	structure in early 1999, my invented definition of that
+	structure became incorrect.  Although I was able to devise
+	a work-around test for the patch with Q4, it was clear that
+	my inventions were bound to cause more problems.
+
+	Discussion with HP about the patch led to my proposing that
+	an lsof API in the HP-UX kernel was the proper solution.
+	Much to my surprise, HP agreed.  I believe Carl Davidson
+	was the prime mover behind that decision, but I know others
+	participated, among them Louis Huemiller, Rich Rauenzahn,
+	and Sailu Yallapragada.  I am indebted to these folks and
+	HP for their willingness to do this work.
+
+	The API was added to the PSTAT interface in a project named
+	PEGL, Pstat Enhancements for Glance and Lsof.  Louis and
+	Sailu did the bulk of the design and implementation work
+	and testing began in March, 2000
+
+	HP-UX 11.11 is the first version that provides PSTAT support
+	for lsof.  HP-UX versions in between 11.0 and 11.11 -- all
+	Beta versions as far as I can determine -- have no lsof
+	support.
+
+	See the "PSTAT-based HP-UX lsof Questions" section for
+	questions and answers specific to PSTAT-based HP-UX lsof.
+	The next section, "Why doesn't a /dev/kmem-based HP-UX lsof
+	compilation use -O?" covers /dev/kmem-based HP-UX lsof.
+
+	The /dev/kmem-based lsof sources may be found in the kmem
+	subdirectory of the dialects/hpux branch of the lsof source
+	tree.  The PSTAT-based lsof sources may be found in
+	.../dialects/hpux/pstat.
+
+9.2	/dev/kmem-based HP-UX lsof Questions
+
+	The sources for /dev/kmem-based lsof for HP-UX may be found
+	in lsof_<revision>/dialects/hpux/kmem.
+
+	Lsof's Configure shell script decides to use these sources
+	when it finds that the /usr/include/sys/pstat subdirectory
+	doesn't exist.
+
+	Lsof can be forced to use the /dev/kmem sources by setting
+	"/dev/kmem" in the HPUX_BASE environment variable.  Consult
+	the Configure shell script and 00XPORTING for more information.
+
+9.2.1	Why doesn't a /dev/kmem-based HP-UX lsof compilation use -O?
+
+	If you only have the standard (bundled) HP-UX C compiler
+	and haven't purchased and installed the optional one, then
+	you can't use cc's -O option.  The HP-UX cc(1) man page
+	says this:
+
+	  "Options
+	     Note that in the following list, the cc and c89 options
+	     -A , -G , -g , -O , -p , -v , -y , +z , and +Z are
+	     not supported by the C compiler provided as part of
+	     the standard HP-UX operating system.  They are supported
+	     by the C compiler sold as an optional separate product."
+
+	Lsof's Configure script tries to detect what C compiler
+	product you have installed by examining your compiler.  If
+	that examination reveals a standard (bundled) compiler,
+	lsof avoids using -O.
+
+	If the Configure compiler test fails, the C compiler will
+	complain that it doesn't support -O.  You can suppress that
+	complaint with this make invocation:
+
+	    $ make DEBUG=""
+	
+9.2.2	Why doesn't the /dev/kmem-based CCITT support work under 10.x?
+
+	Pasi Kaara, who originally provided the HP-UX CCITT support,
+	reports that it no longer works under HP-UX 10.x.
+	Consequently, at lsof revision 4.02 it has been disabled.
+
+9.2.3	Why can't /dev/kmem-based lsof be compiled with `cc -Aa` or
+	`gcc -ansi` under HP-UX 10.x?
+
+	Some HP-UX 10.x header files, needed by lsof, can't be
+	compiled properly in ANSI_C mode; structure element definition
+	and alignment problems result.  The f_offset member of the
+	file structure, for example, is incorrect.
+
+	This ANSI-C obstacle extends to using the -Aa option of
+	the HP C compiler and the -ansi option of gcc.
+
+9.2.4	Why does /dev/kmem-based lsof complain about no C compiler?
+
+	Lsof's Configure script looks in /bin and /usr/ccs/bin for
+	an HP C compiler, because it needs to know if the compiler
+	is the standard (bundled) one or the optional separate
+	product.  If it finds no compiler in either place, Configure
+	quits after complaining:
+
+	    No executable cc in /bin or /usr/ccs/bin
+
+	If you don't have a C compiler in either of these standard
+	places, you should consider installing it.  If you have
+	gcc installed, you can use it by declaring the ``hpuxgcc''
+	abbreviation to lsof's Configure script.
+
+	If you have a C compiler in a non-standard location, you
+	can use the HPUX_CCDIR[12] environment variables to name
+	the path to it.  Consult the 00XCONFIG file of the lsof
+	distribution for more information.
+
+9.2.5	Why does Configure complain about q4 for /dev/kmem-based lsof
+	for HP-UX 11?
+
+	When you run Configure on an HP-UX 11 system, it may complain:
+
+	  !!!ERROR!!!     !!!ERROR!!!     !!!ERROR!!!     !!!ERROR!!!
+	  Configure can't use /usr/contrib/bin/q4 to examine the ipis_s
+	  structure.  You must do that yourself, report the result in
+	  the HPUX_IPC_S_PATCH environment variable, then repeat the
+	  Configure step.  Consult the Configure script's use of
+	  /usr/contrib/bin/q4 and the 00XCONFIG file for information
+	  on ipis_s testing and the setting of HPUX_IPC_S_PATCH.
+	  !!!ERROR!!!     !!!ERROR!!!     !!!ERROR!!!     !!!ERROR!!!
+
+	This message states that Configure cannot use q4 from
+	/usr/contrib/bin to examine the kernel's boot image for
+	the ipis_s structure.  Maybe q4 hasn't been installed, or
+	perhaps Configure can't execute it.
+
+	Lsof needs to gather information about ipis_s to determine
+	if the ipis_s structure is defined in the kernel boot image,
+	if the ipis_s structure of the kernel boot image has an
+	ipis_msgsqueued member, and if the ipc_s structure of the
+	kernel boot image uses has an ipc_ipis member.
+
+	The ipis_s structure isn't described in any header file
+	HP-UX releases with HP-UX 11.  It appears in the private
+	lsof header file .../dialects/hpux/kmem/hpux11/ipc_s.h.
+	Lsof gets local and remote connection addresses (IP and
+	port numbers) from ipc_s, so an incorrect ipc_s definition
+	may cause incorrect reporting of TCP/IP connection addresses.
+	It definitely will cause incorrect reporting on 32 bit
+	kernels.  In any case lsof should be compiled with a correct
+	ipc_s definition no matter the kernel bit size, so the
+	Configure script always tests for it when the HP-UX version
+	is 11.
+
+	For lsof's Configure script to gather the necessary ipis_s
+	information q4 needs to be installed in /usr/contrib/bin
+	and the kernel boot image, /stand/vmunix, needs to have
+	been processed with pxdb.  If either is untrue, lsof issues
+	the above error message, perhaps preceded by q4 messages.
+	(Note: lsof's use of q4 may also fail if q4 can't execute
+	nm -- e.g., it can't find /usr/bin/nm, or there is a
+	conflicting, private version of nm earlier in the path.)
+
+	If /stand/vmunix hasn't been processed by pxdb, the q4
+	messages will include:
+
+	    q4: (error) vmunix not pxdb'd
+	or
+	    q4: (warning) /stand/vmunix has not been processed by pxdb.
+
+	It's possible to make a suitable private copy of /stand/vmunix
+	for configuring lsof.  That requires /opt/langtools/bin/pxdb
+	or the q4 version of pxdb from /usr/contrib/bin/q4pxdb.
+	The path to the result is supplied to the lsof Configure
+	script in the HPUX_BOOTFILE environment variable.  Configure
+	still requires /usr/contrib/bin/q4.
+
+	The following sample Bourne shell commands make a private
+	copy of /stand/vmunix in /tmp, process it with pxdb or
+	q4pxdb, and supply its path to lsof's Configure script in
+	HPUX_BOOTFILE.
+
+	    $ cp /stand/vmunix /tmp/vmunix.lsof
+
+	    $ /opt/langtools/bin/pxdb /tmp/vmunix.lsof
+	  or
+	    $ /usr/contrib/bin/q4pxdb /tmp/vmunix.lsof
+
+	    ... pxdb messages ...
+	    $ HPUX_BOOTFILE=/tmp/vmunix.lsof Configure -n hpux
+
+	It may also be necessary to use q4 outside the lsof Configure
+	script.  In that case q4 can be to determine the state of
+	ipis_s and ipc_s with these q4 commands:
+
+	    $ /usr/contrib/bin/q4 /stand/vmunix
+	    ...
+	    q4> fields -c struct ipc_s
+	    ...
+	    q4> fields -c struct ipis_s
+
+	Look in the q4 output for the ipc_ipis member of the ipc_s
+	structure, and look in the q4 output for the ipis_s structure
+	for the ipis_msgsqueued member.  If ipc_s has ipc_ipis but
+	ipis_s lacks ipis_msgsqueued, set HPUX_IPC_S_PATCH environment
+	variable to "1".  If ipc_s has ipc_ipis and ipis_s has
+	ipis_msgsqueued, set HPUX_IPC_S_PATCH to "2" -- e.g.,
+
+	    $ HPUX_IPC_S_PATCH=1 Configure -n hpux
+	  or
+	    $ HPUX_IPC_S_PATCH=2 Configure -n hpux
+
+	If ipc_s has no ipc_ipis member, set HPUX_IPC_S_PATCH to
+	"N" -- e.g., use this Configure step:
+
+	    $ HPUX_IPC_S_PATCH=N Configure -n hpux
+
+9.2.6	When compiling /dev/kmem-based lsof for HP-UX 11 what do the
+	"aCC runtime: ERROR..." messages mean?
+
+	When the lsof Makefile asks the HP-UX unbundled compiler
+	to load lsof, it may complain:
+
+	    /bin/cc -o lsof  -DHPUXV=1100 -DHASVXFS -DHPUXKERNBITS=64 \
+		-I/home/abe/src/lsof4/dialects/hpux/kmem/hpux11 +DD64 \
+		-DHAS_IPC_S_PATCH=2 -I/home/abe/src/lsof4/dialects/hpux/kmem \
+		-DLSOF_VSTR=\"B.11.00\"  -g dfile.o dmnt.o dnode.o dnode1.o \
+		dnode2.o dproc.o dsock.o  dstore.o  arg.o main.o misc.o \
+		node.o print.o proc.o store.o usage.o -L./lib -llsof  -lelf \
+		-lnsl
+	    aCC runtime: ERROR: Unexpected use of shared libraries
+	    aCC runtime: ERROR: Read aCC manpage, +A option
+	    /usr/lib/nls/loc/locales.1//is_IS.iso88591
+
+	This is a bug in the HP-UX national language support.
+	(Notice the last message with "locales" in it?)  Complain
+	to HP -- then use this work-around before executing make:
+
+	    $ unset LANG
+	    $ make
+
+9.2.7	Why doesn't /dev/kmem-based lsof for HP-UX 11 report VxFS file
+	link counts, node numbers, and sizes correctly?
+
+	This is usually the result of running an lsof binary whose
+	revision number is less than 4.57 on a system that has
+	OnlineJFS support installed.  It can also happen with lsof
+	4.57 binaries when the OnlineJFS support with which they
+	were built doesn't match the OnlineJFS status of the system
+	on which they are run.
+
+	The OnlineJFS status of lsof 4.57 and higher binaries can
+	be determined by running:
+
+	    $ lsof -v 2>&1 | grep HASONLINEJFS
+
+	If that shell pipe produces output, lsof was compiled with
+	OnlineJFS support enabled; no output, disabled.
+
+	If OnlineJFS is installed on an HP-UX 11 system the
+	/sbin/fs/vxfs/subtype executable exists and outputs "vxfs3.3"
+	when run.
+
+	The problem occurs because the optional OnlineJFS support
+	installation doesn't update <sys/fs/vx_inode.h>.  Consequently
+	lsof can be compiled with an incorrect definition of the
+	vx_inode structure and look for for link counts, node
+	numbers, and sizes in the wrong places in the structure.
+
+	The current response I have gotten from HP is that no
+	<sys/fs/vx_inode.h> update will be provided for OnlineJFS.
+
+	I've addressed this problem temporarily with a work-around
+	(hack) in lsof revision 4.57.
+
+9.2.8	Why can't /dev/kmem-based lsof be built with gcc for 64 bit
+	HP-UX 11?
+
+	When Configure is given the "hpuxgcc" abbreviation, the
+	HP-UX version is 11, and the kernel bit size is 64, the
+	lsof Configure script may abort with the messages:
+
+	    !!!!!!!!!!!!!!!!! FATAL ERROR !!!!!!!!!!!!!!!!!!
+
+	    APPARENTLY GCC CANNOT BUILD 64 BIT EXECUTABLES.
+	    A COMPILER MUST BE USED THAT CAN.  SEE 00FAQ
+	    FOR MORE INFORMATION.
+
+	(This is the "more information" in 00FAQ.)
+
+	This means the Configure script compiled a test program
+	with gcc the result wasn't an ELF-64 binary.  Lsof tries
+	two gcc modes, one with no options and another with the
+	-mlp64 option, before it concludes gcc can't be used.
+
+	See the "How can I acquire a gcc for building lsof for 64
+	bit HP-UX 11?" answer for information on where you might
+	be able to get a gcc for HP-UX 11 that can produce ELF-64
+	executables.
+
+9.2.8.1	How can I acquire a gcc for building lsof for 64 bit HP-UX 11?
+
+	Check this HP URL:
+
+	  http://h21007.www2.hp.com/dspp/tech/tech_TechSoftwareDetailPage_IDX/1,1703,547,00.html
+
+	(That's one very long link; be careful you cut 'n paste it
+	all.)
+
+	In November 2001 that URL led to a web page whose title
+	was "gcc for hp-ux 11."  The page offered a link for
+	downloading a 64 bit gcc 3.0 compiler for HP-UX 11.0 and
+	11i.  Rich Rauenzahn of HP installed that compiler on an
+	HP test system he allows me to use and I successfully built
+	a 64 bit lsof with it.
+
+	The HP package may install the 64 bit capable gcc in
+	/usr/local/pa20_64/bin/gcc, so you may have to adjust your
+	path or set the LSOF_CC environment variable to compensate.
+
+9.2.9   Why does /dev/kmem-based lsof for HP-UX 11 report "unknown file
+	system type" for some open files?
+
+	The lsof binary being used probably doesn't have support for
+	the VxFS file system.
+
+	To confirm that, check `lsof -v` output for "-DHASVXFS".  If
+	it's not present, lsof doesn't have VxFS support.
+
+	You also need to establish that lsof really is complaining
+	about VxFS files by checking the kernel boot file for the
+	symbol associated with the hexadecimal address reported in the
+	"unknown file system type" message -- e.g., "v_op: 0x8711c8."
+	Use nm(1) to do that:
+
+	    $ nm -x /stand/vmunix | grep 8711c8
+
+	If nm reports the symbol associated with the address is
+	vx_vnodeops, then lsof is complaining about an open VxFS file.
+
+	The solution in that case is to build lsof yourself (The
+	bundled C compiler will do it.), making sure that lsof's
+	Configure script detects the presence of VxFS.  Configure does
+	that by finding these two header files:
+
+	    /usr/include/sys/fs/vx_hpux.h
+	    /usr/include/sys/fs/vx_inode.h
+
+	If the system where you are building lsof doesn't have those
+	header files, but does have VxFS, you might be able to install
+	the header files by installing the HP JournalFS package from
+	the CoreOS CD -- in particular the file set JournalFS.VXFS-PRG
+	and its associated patch, PHKL_18543.  (My thanks to Steve
+	Bonds for that information.)
+
+	Finally, if you find that lsof isn't complaining about VxFS
+	when it complains about an unknown file system type, send
+	e-mail to me <abe@purdue.edu> for further assistance.  Make
+	sure "lsof" appears in the "Subject:" line so my e-mail filter
+	won't classify your letter as Spam.
+
+9.2.10	Why does the ANSI-C compiler complain about comments in HP-UX
+	11 header files?
+
+	When compiling lsof on HP-UX 11, the HP ANSI-C compiler's
+	pre-processor, cpp, may complain about comments in HP-UX header
+	files -- e.g.,
+
+	    cpp: "/usr/include/sys/cdfs.h", line 232: warning 2028:
+		Found comment inside comment started on line 232.
+	    cpp: "/usr/include/sys/cdnode.h", line 196: warning 2028:
+		Found comment inside comment started on line 196.
+	    cpp: "/usr/include/nfs/snode.h", line 30: warning 2028:
+		Found comment inside comment started on line 30
+
+	This is not a problem with lsof.  It is a problem with the
+	HP-UX header files; they have non-compliant ANSI-C comment
+	sequences in them -- e.g.,
+
+	    <sys/cdfs.h>: 232
+		/* struct  cdfs *cdfs_link;  /* linked list of file systems */
+
+	The initial "/*" is not terminated by an ending "*/" before the
+	appearance of a second "/*".
+
+9.2.11  Why does dnode1.c cause the HP-UX 11 compiler to complain that
+	<sys/fs/vx_inode.h> is missing or incorrect?
+
+	If CFLAGS in the lsof Makefile for an HP-UX 11 compilation
+	includes HASONLINEJFS, indicating the system has OnlineJFS
+	support, lsof needs the <sys/fs/vx_inode.h> header file.
+	Sometimes it is missing from /usr/include/sys/fs.
+
+	<sys/fs/vx_inode.h> is a header file that must be obtained from
+	Veritas.  If that proves impossible, please contact me via
+	e-mail at <abe@purdue.edu>.  Make sure "lsof" appears in the
+	"Subject:" line so my e-mail filter won't classify your letter
+	as Spam.
+
+
+9.3	PSTAT-based HP-UX lsof Questions
+
+	The sources for PSTAT-based lsof for HP-UX may be found in
+	lsof_<revision>/dialects/hpux/pstat.
+
+	Lsof's Configure shell script decides to use these sources
+	when it finds that the /usr/include/sys/pstat subdirectory
+	exists.
+
+	Lsof can be forced to use the PSTAT-based sources by setting
+	"pstat" in the HPUX_BASE environment variable.  Consult
+	the Configure shell script and 00XPORTING for more information.
+
+9.3.1	Why does PSTAT-based lsof complain about pst_static and
+	other PSTAT structures?
+
+	When lsof starts it may issue one of these fatal error
+	messages:
+
+	    lsof: FATAL: can't determine PSTAT static size
+	    lsof: FATAL: can't read <n> bytes of pst_static
+	    lsof: FATAL: pst_static doesn't contain <name>_size
+	    lsof: FATAL: <name>_size should be <n>
+
+	These messages indicate that lsof's tests for the proper
+	level of PSTAT support have failed.  The structure names,
+	given in <name>, and sizes, given in <n>, identify the
+	support deficiency more precisely.
+
+	You may need to upgrade the PSTAT support in your kernel
+	to be able to use PSTAT-based lsof.
+
+9.3.2	Why does PSTAT-based lsof complain it can't read pst_*
+	structures?
+
+	Lsof may put messages like the following in the NAME
+	column of its output.
+
+	    can't read cwd pst_filedetails: Permission denied
+	    can't read mem pst_filedetails: Permission denied
+	    can't read rtd pst_filedetails: Permission denied
+	    can't read txt pst_filedetails: Permission denied
+	    can't read pst_filedetails: Permission denied
+	    can't read 3 stream structures: Permission denied
+	    can't read pst_socket: Permission denied
+
+	These messages indicate that the lsof binary lacks the
+	authority to read the name structures for processes other
+	than ones belonging to the UID under which lsof is running.
+	Authority to read the structures of other processes is
+	limited to root processes -- i.e., lsof must have setuid-root
+	permission if it is to list open files for arbitrary
+	processes.
+
+	If you want to eliminate these errors, you must run lsof
+	as root or install it with setuid-root permission.
+
+9.3.3	Why does PSTAT-based lsof rebuild the device cache file
+	after each reboot?
+
+	After each HP-UX rebuild, the first time a user runs lsof it
+	will report:
+
+	    lsof: WARNING: device cache mismatch: /dev/tun...
+	    lsof: WARNING: created device cache file: /<user_path>
+
+	This happens because the device numbers on /dev/tun* device
+	nodes are recalculated at each reboot.  When lsof detects
+	a change in the device number of a /dev/tun* file, it rebuilds
+	its local device cache file.
+
+9.3.4	Why doesn't PSTAT-based lsof report TCP addresses for
+	telnetd's open socket files?
+
+	When lsof can't report TCP addresses for telnetd's open
+	socket files it is because an unpatched PSTAT kernel
+	interface doesn't report the addresses to lsof.
+
+	This has been addressed in PSTAT kernel patch PHKL_24047.
+	It is available from the HP IT Resource Center at:
+
+	    http://itrc.hp.com
+
+	In the page's "maintenance / support" box select the
+	"individual patches" link.  Once at its page, select the
+	"hp-ux" link.  On that page select the "Series 800" or
+	"Series 700" radio button and select "11.11" from the
+	pull-down list to the right of the button.  Under "search
+	or browse the path list" select "Search by Patch IDs" from
+	the pull down list, enter PHKL_24047 in the following text
+	box, and select search.  That should lead to information
+	about PHKL_24047 and a link for downloading it.  (You may
+	have to log in first and you may have to create a login
+	identity by registering before you can log in.)
+
+	Some time in March 2006 the PHKL_24047 patch was "lost"
+	by the HP-UX networking lab.  It has been "found" again
+	in August 2006 and will be re-released as a GRO patch
+	"some time."  I don't yet know when that will be.  You
+	must contact HP to learn about the availability of the
+	GRO patch.
+
+9.3.5	Why does PSTAT-based lsof cause an HP-UX 11.11 kernel panic?
+
+	When PSTAT-based lsof runs on some HP-UX 11.11 kernels,
+	the kernel may panic.  Symptoms include:
+
+	  Console message:
+	    0xFBE000301100EF00 00000000 0000EF00 -
+	    type 31 = legacy PA HEX chassis-code
+
+	  /var/adm/syslog:
+	    ... vmunix: Trap Type 15 (Data page fault)
+	    ... vmunix:   Instruction Address (pcsq.pcoq) = 0x...
+
+	The panic is caused by a bug in the way PSTAT's pstat_getstream()
+	function obtains module names from streams managed by the
+	otsam stream driver (part of OSI Transport Services).  Lsof
+	calls pstat_getstream() when it encounters an open otsam
+	stream file.  An HP-UX 11.11 system uses otsam if otsam
+	appears in /stand/system.
+
+	HP-UX 11.11 patch PHKL_24507 (available some time after
+	July 15, 2001) fixes the pstat_getstream() bug.  See the
+	information in the answer to the "Why doesn't PSTAT-based
+	lsof report TCP addresses for telnetd's open socket files?"
+	question for information on how to obtain the patch.
+
+9.3.6   Why doesn't PSTAT-based lsof report a CWD that is on a loopback
+	(LOFS) file system?
+
+	When PSTAT-based lsof reports on processes whose current
+	working directory (CWD) is on a loopback file system, lsof
+	can't report the open CWD file.  The reason is that the HP-UX
+	11.11 and above kernel's loopback file system code is not
+	passing the CWD file ID to the kernel's pstat(2) code.  Hence
+	lsof is given no information on the lofs CWD.
+
+	The problem was first reported to me by Ermin Borovac and an
+	internal bug report was filed with the HP-UX file system group
+	on October 26, 2004.  That report has now been answered by the
+	patch PHKL_33200 -- s700_800 11.11 lofs cumulative patch.  The
+	HP IT Resource Center (http://itrc.hp.com) is a source for the
+	patch.
+
+9.3.7	Why do some swinstall packages for PSTAT-based HP-UX 11.11
+	packages complain about setgid and setuid bits?
+
+	First, let me explain that I do not provide lsof swinstall
+	packages for lsof.  Others provide them and they should be
+	contacted about problems with their packages.
+
+	However, I have become aware of a problem with one package
+	about which I have some information I can share.  The problem
+	shows up in these swinstall messages:
+
+	    ERROR:   Unknown owner and/or group for file
+		     "/usr/local/bin/lsof". SUID and/or SGID bit was
+		     not set. 
+	    ERROR:   Failed installing fileset "lsof.lsof-RUN,r=4.73".
+		     Check the above output for details.
+
+	The swpackage SUID/SGID functionality was restricted by changes
+	for POSIX compliance, breaking backward compatibility.  The
+	patch PHCO_27671 allows SUID/SGID for uid/gid of 0 only, as a
+	compromise between backward compatibility and POSIX conformance.
+
+	If the setuid bit is to be set on the executable, the UID and
+	GID of the executable must be 0 (zero).
+
+9.3.8	Why won't the bundled C compiler build PSTAT-based lsof for
+	PA-RISC HP-UX 11.23?
+
+	A PA-RISC HP-UX 11.23 bundled C compiler dated May 2005 or
+	later will not build PSTAT-based lsof.  It will deliver error
+	messages related to the system's <gssapi/gssapi.h> header
+	file.
+
+	There is nothing wrong with that header file or lsof.  The
+	problem is that the bundled C compiler can't cope with the
+	gssapi.h header file.
+
+	The work-around is to use the HP ANSI C compiler.   Using gcc
+	is not a satisfactory work-around.  See the answer to the "Why
+	won't gcc build PSTAT-based lsof for PA-RISC HP-UX 11.23?"
+	question for more information.
+
+9.3.9	Why won't gcc build PSTAT-based lsof for PA-RISC HP-UX 11.23?
+
+	Gcc will not even compile PSTAT-based lsof revisions below 4.77
+	for PA-RISC HP-UX 11.23 dated May 2005 or later.  It reports
+	errors in lsof's print.c fill_portmap() function about missing
+	members of the rpcent structure.  That happens because gcc
+	defines _XOPEN_SOURCE_EXTENDED which disables the definition of
+	the rpcent structure in <netdb.h>.
+	
+	Using the HP bundled C compiler is not a viable work-around.
+	That is explained in the answer to the "Why won't the bundled C
+	compiler build PSTAT-based lsof for PA-RISC HP-UX 11.23?"
+
+	While an lsof revision 4.77 or higher can be compiled with gcc,
+	the results are unreliable.  Lsof will compile, but it
+	occasionally produces segment faults when it runs.  I have not
+	been able to reproduce the failure reliably or locate a
+	debugger that will work with the gcc-compiled lsof.
+
+	The only reliable work-around is to use the HP ANSI C
+	compiler.
+
+9.3.10	Why does PSTAT-based lsof complain, "FATAL: pst_stream_size
+	should be: 672; is 72" on HP-UX 11.11 and above?
+
+	This message indicates a mismatch between the PSTAT header
+	files used to build lsof (<sys/pstat.h> and those in the
+	/usr/include/sys/pstat subdirectory), and those that built the
+	running kernel.
+
+	Unfortunately the June 2008 patch set for HP-UX 11.23 creates
+	this inconsistency, because it does not contain all the patches
+	needed to match the kernel with the PSTAT header files.  Even
+	more serious is that the missing patches update the kernel's
+	PSTAT support to provide TCP/UDP endpoint information to lsof
+	from TCP/TLI streams.
+
+	The patch inconsistency comes about because, while the following
+	patch is installed,
+
+	    PHKL_36577  1.0  PM-PSTAT section 2 manpage changes
+
+	other kernel patches are not.
+
+	The PHKL_36577 patch updates the PSTAT header files and manual
+	pages to match kernel changes that other patches with the
+	following numbers (or patches that contain or supersede them)
+	contain:
+
+	    PHNE_36575  1.0  Cumulative STREAMS Patch
+	    PHNE_37670  1.0  cumulative ARPA Transport patch
+	    PHNE_37851  1.0  NFS cumulative patch
+
+	Those patches implement the kernel changes that support the
+	delivery of information promised in patch PHKL_36577.
+
+	The work-around is to install the missing patches.
+
+9.4	Why won't the HP-UX depot install?
+
+	I don't distribute lsof depots, so I can't support them.
+
+	From time to time depots prepared by various sites -- e.g.,
+	usually HP-UX software collection sites -- will contain errors
+	that cause installation of the depot to fail.
+
+	Do not contact me when this happens.  Instead, contact the
+	administrator of the site that prepared the depot.
+
+	As should be clear from the bulk of the lsof documentation, I
+	do not recommend you use pre-built lsof binaries in any form.
+	Instead, I recommend you obtain the lsof source distribution
+	and build lsof yourself.
+
+
+10.0	Linux
+
+10.1	What do /dev/kmem-based and /proc-based lsof mean?
+
+	At approximately Linux 2.1.72 and exactly at lsof revision
+	4.23 support for Linux forks.  The first fork, containing
+	the oldest lsof form is based on access to kernel memory
+	structures, and is called /dev/kmem-based lsof.  A
+	/dev/kmem-based lsof is heavily intertwined with the Linux
+	kernel version, its header files, and its system map file.
+	Typically a /dev/kmem-based lsof needs only setgid permission
+	to local all open file information.
+
+	After approximately Linux 2.1.72 and at revision 4.23 lsof
+	obtains all its information from the /proc file system.
+	That lsof is called the /proc-based lsof.  A /proc-based
+	lsof does not read kernel memory, needs neither kernel
+	header files nor the system map file, and is less likely
+	to be affected by Linux kernel changes.  However, it does
+	require setuid-root permission to list all open files, and
+	it can't report file offsets (positions).
+
+	After revision 4.52 the /dev/kmem-based Linux sources for
+	lsof are no longer distributed.  Information about them
+	may be found in the 00INDEX and README files at:
+
+	    ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/OLD/src
+
+10.2	/proc-based Linux lsof Questions
+
+10.2.1	Why doesn't /proc-based lsof report file offsets (positions)?
+
+	/proc-based lsof revisions 4.79 and above can only report file
+	offsets (positions) for the files of Linux kernels 2.6.22 and
+	above.
+
+	During its initialization /proc-based lsof tests to see if
+	offset information can be obtained.  If it cannot, lsof
+	disables offset reporting.  If the -o option was selected, lsof
+	also issues this warning:
+
+	    lsof: WARNING: can't report offset; disregarding -o.
+
+
+10.2.2	Why does /proc-based lsof report "can't identify protocol" for
+	some socket files?
+
+	/proc-based lsof may report:
+
+	    COMMAND PID ... TYPE ... NODE NAME
+	    pump    226 ... sock ...  309 can't identify protocol
+
+	This means that it can't identify the protocol (i.e., the
+	AF_* designation) being used by the open socket file.  Lsof
+	identifies protocols by matching the node number associated
+	with the /proc/<PID>/fd entry to the node numbers found in
+	selected files of the /proc/net sub-directory.  Currently
+	/proc-based lsof examines these protocol files:
+
+	    /proc/net/ax25		(untested)
+	    /proc/net/icmp
+	    /proc/net/ipx		(needs kernel patch)
+	    /proc/net/netlink
+	    /proc/net/packet
+	    /proc/net/raw
+	    /proc/net/raw6
+	    /proc/net/sctp/assocs
+	    /proc/net/sctp/eps
+	    /proc/net/sockstat
+	    /proc/net/sockstat6
+	    /proc/net/tcp
+	    /proc/net/tcp6
+	    /proc/net/udp
+	    /proc/net/udp6
+	    /proc/net/udplite
+	    /proc/net/udplite6
+	    /proc/net/unix
+
+	If /proc-based lsof says it can't identify the protocol
+	for an open socket file, you may be able to identify the
+	protocol yourself by using grep to look for the specific
+	node number in the files of /proc/net -- e.g.,
+
+	    $ grep <node_number> /proc/net/*
+
+	You may not be able to find the desired node number, because
+	not all kernel protocol modules fully support /proc/net
+	information.
+
+	If you find a matching node number in a /proc/net file that is
+	not currently being processed by lsof, contact me via e-mail at
+	<abe@purdue.edu>.  I'll discuss adding support to /proc-based
+	lsof for the protocol of the /proc/net file with you.  Make
+	sure "lsof" appears in the "Subject:" line so my e-mail filter
+	won't classify your letter as Spam.
+
+	The code that matches node numbers of open IPX protocol
+	socket files to those in /proc/net/ipx requires Jonathan
+	Sergent's Linux 2.1.79 patch to /usr/src/linux/net/ipx/af_ipx.c.
+	The patch, suitable for input to Larry Wall's patch program,
+	may be found in the lsof distribution file:
+
+	    .../dialects/linux/proc/patches/net_ipx_af_ipx.c.patch
+
+10.2.3	Why does /proc-based lsof warn about unsupported formats?
+
+	Lsof may issue the following warning:
+
+	    lsof: WARNING: unsupported format: /proc/net/<file>
+
+	if the header line of the indicated <file> in /proc/net --
+	ax25, ipx, raw, tcp, udp, or unix -- doesn't match what
+	lsof expects to find.
+
+	When the header line of a /proc/net file isn't what lsof
+	expects, lsof probably can't parse the rest of the file
+	correctly and doesn't try.  As a result, lsof can't report
+	any NAME column information (e.g., local and remote addresses)
+	for socket files bound to the indicated network protocol.
+
+	If you get this warning, please send me e-mail at <abe@purdue.edu>.
+	Include the contents of the file lsof claims has an unsupported
+	format.  Make sure "lsof" appears in the "Subject:" line so my
+	e-mail filter won't classify your letter as Spam.
+
+10.2.4   Why does /proc-based lsof report "(deleted)" after a path name?
+
+	The "(deleted)" notation following a path name in /proc-based
+	lsof's NAME column comes from the /proc/<PID>/fd/<FD> entry
+	for the open file.  It's the Linux kernel's way of indicating
+	the file is open but has been unlinked (rm'd).
+
+10.2.5	Why doesn't /proc-based lsof report full open file information
+	for all processes?
+
+	/proc-based lsof can only report on processes whose /proc
+	files it has permission to read.  /proc normally grants
+	permission to read all its files only to root or to the
+	owning user ID.
+
+	Without permission to read most /proc files, lsof can only
+	report full information for processes belonging to the user
+	who is running lsof.  /proc-based lsof may be able to report
+	some information for all processes, depending on the
+	permissions of their associated /proc files, but usually
+	/proc-based lsof won't be able to access the files in
+	/proc/<PID>/fd/ that describe regular open files.
+
+	If you want /proc-based lsof to report on all processes, you
+	must install it with setuid-root permission.
+
+10.2.6	Why won't Customize offer to change HASDCACHE or WARNDEVACCESS
+	for /proc-based lsof?
+
+	/proc-based lsof doesn't read device information from /dev
+	or the device cache file, so it makes no sense to change
+	the state of device cache processing or /dev node accessibility
+	warnings.
+
+10.2.7	/proc-based lsof Linux NFS questions
+
+10.2.7.1 Why can't lsof find files on an accessible NFS file system?
+
+	On occasion lsof may be unable to identify that an open
+	file is on an NFS file system.  This is most likely the
+	result of a bug in the way the Linux kernel supplies
+	information to the reader of /proc/mounts (lsof) -- sometimes
+	that pseudo-file is truncated by the kernel.
+
+	One way to see if this is the case is to search for the
+	NFS file system in /proc/mounts -- e.g.,
+
+	    $ grep <NFS_file_system_mount_point> /proc/mounts
+
+	If you get no output or the third word of the output isn't
+	"nfs", then lsof won't consider the file system an NFS file
+	system.
+
+	A second test is to look at the end of /proc/mounts --
+	e.g.,
+
+	    $ tail /proc/mounts
+
+	If tail reports "# truncated" then /proc/mounts is incomplete
+	because of a Linux kernel bug.  The bug is documented at:
+
+	    http://www.xss.co.at/sysinfo/mounts.html
+
+	The bug is fixed in Linux kernel 2.4.18, and possibly in
+	some earlier Linux kernel versions.
+
+10.2.7.2 Why can't lsof find files on an inaccessible NFS file system?
+
+	If lsof issues this message about a Linux file system,
+	mounted from an NFS server:
+
+	    lsof: WARNING: can't stat() nfs file system /xxx/yyy
+
+	Then lsof won't be able to find any open files on the file
+	system.
+
+	That's because of an inadequacy in the Linux /proc file
+	system.  Its /proc/mounts file doesn't give the device
+	doublet (major and minor numbers) of the file system as do
+	many UNIX systems (e.g., Solaris).  The only way lsof can
+	get the device doublet for a Linux file system is to call
+	stat(2) on the file system path, which fails if the NFS
+	server isn't accessible.
+
+	When lsof doesn't know the device doublet of a file system,
+	it can't find open files on the inaccessible file system,
+	because it can't match the doublets of open files to the
+	doublet of the inaccessible file system.
+
+	This topic is covered extensively in lsof(8) it its ALTERNATE
+	DEVICE NUMBERS and BLOCKS AND TIMEOUTS sections.
+
+10.2.8	Why doesn't /proc-based Linux lsof report socket options and
+	values, socket state flags, and TCP options and values?
+
+	The Linux /proc file system doesn't report socket options
+	and values, socket states, and TCP options and values to
+	lsof.
+
+10.2.9	Does /proc-based Linux lsof use a device cache?
+
+	No.  The Linux /proc/<PID>/fd/* entries provide device names to
+	lsof via readlink(2).  It is not necessary to enable device
+	cache processing for /proc-based Linux lsof via the Customize
+	script or modifications to the Linux machine.h header file.
+
+10.2.10	Why doesn't /proc-based Linux lsof report any or all file structure
+	values for its +fcfgGn option?
+
+	/proc-based lsof revisions 4.79 and above can only report some
+	file structure values for Linux kernels below 2.6.22.
+
+	When running on Linux kernels at 2.6.22 and above lsof 4.79 can
+	report some file flag values -- i.e., in response to the +fg or
+	+fG options.  The flag values are obtained from the
+	/proc/<PID>/fdinfo/ files introduced at Linux kernel 2.6.22.
+
+	/proc-based Linux lsof tests its availability to obtain file
+	flag values at initialization.  If values are not available,
+	lsof disables file flag reporting.  If the flags were requested
+	with +fg or +fG, lsof displays this warning:
+
+	    lsof: WARNING: can't report file flags; disregarding +f.
+
+	As a special note, when Linux lsof can report flag bits, it
+	will not report 'R' for a read-only file.  There is no
+	read-only flag bit O_* symbol in <fcntl.h> (or <bits/fcntl.h>)
+	and lsof reports only bits that are set.  The absence of O_RDWR
+	and O_WRONLY flag bits implies the file is read-only.
+
+10.3	Special Linux file types
+
+10.3.1	Why is ``DEL'' reported as a Linux file type?
+
+	Lsof usually reports entries from the Linux /proc/<PID>/maps
+	file with ``mem'' in the TYPE column.  However, when lsof can't
+	stat(2) a path in the process' ``maps'' file and the ``maps''
+	file entry contains ``(deleted)'', indicating the file was
+	deleted after it had been opened, lsof reports the file type as
+	``DEL''.
+
+10.3.2	Why is ``unknown'' reported as a Linux file type?
+
+	Lsof may report a Linux file's type as ``unknown'' in the TYPE
+	column when lsof can't obtain complete stat(2) results for the
+	file.
+
+	Usually the NAME column will contain a ``(stat: xxx)'' error
+	message, but that could have been suppressed with the lsof
+	``-w'' option.
+
+10.4	Linux ``mem'' Entry Problems
+
+10.4.1  What do ``path dev=xxx'' and ``path inode=yyy'' mean in the
+	NAME column of Linux ``mem'' file types?
+
+	When the device or inode number in the process' ``maps'' file
+	entry doesn't match the stat(2) results from the file path,
+	lsof reports the inconsistent information from the stat(2) of
+	the path parenthetically after the path in the NAME column
+	in one of these forms:
+
+	    (path dev=xxx)              only the device number,
+					``xxx'', from a stat(2) of the
+					``maps'' file entry path
+					differs from the ``maps'' file
+					entry value reported in the
+					DEVICE column.
+
+	    (path inode=yyy)		only the inode number,
+					``yyy'', from a stat(2) of the
+					``maps'' file entry path
+					differs from the ``maps'' file
+					entry value reported in the
+					NODE column.
+
+	    (path dev=xxx inode=yyy)    Both device and inode numbers
+					differ.
+
+	Lsof reports the ``maps'' file device number in the DEVICE
+	column and the inode number in the NODE column.
+
+	When device and inode mismatches occur, lsof suppresses the
+	reporting of link count and size.  See the answer to the "Why
+	is neither link count nor size reported for some Linux ``DEL''
+	and ``mem'' file types?" question for more information.
+
+	Device and inode inconsistencies can occur when a file at a
+	``maps'' path is replaced after the process has started, or
+	when a different file system with similar path names is mounted
+	on top of the original file system.
+
+	The device inconsistency parenthetical messages can be
+	suppressed with lsof's ``-w'' option.
+
+10.4.2  Why is neither link count nor size reported for some Linux
+	``DEL'' and ``mem'' file types?
+
+	Link count and size are not reported for some entries from the
+	process' ``maps'' file because a stat(2) of the entry file path
+	failed or stat(2) delivered device or inode numbers that don't
+	match the ones in the ``maps'' entry.
+
+	When the stat(2) device or inode numbers don't match those in
+	the ``maps'' file entry, it is likely that the stat(2) results
+	don't apply to the file that was originally mapped by the
+	process and whose path appears in the ``maps'' file entry, so
+	lsof tries to avoid reporting possibly incorrect information.
+
+	See the answer to the "What do ``path dev=xxx'' and ``path
+	inode=yyy'' mean in the NAME column of Linux ``mem'' file
+	types?" for more information on how mismatched stat(2) device
+	and inode numbers are reported.
+
+10.5	Special Linux NAME column messages
+
+10.5.1  What does ``(stat: xxx)'' mean in the NAME column of Linux
+	files?
+
+	When lsof tried to stat(2) the path in the NAME column, the
+	stat(2) system call failed and produced an error message of
+	``xxx''.
+
+	This situation usually occurs if the lsof process lacks
+	permission to stat(2) the path -- e.g., the lsof executable
+	lacks root permission, or lsof is attempting to stat(2) a path
+	on an NFS device mounted with the root_squash option.
+
+	The message can be suppressed with lsof's ``-w'' option.
+
+10.5.2  What does ``(readlink: xxx)'' mean in the NAME column of
+	Linux files?
+
+	When lsof tried to convert the /proc/<PID>/fd path, reported in
+	the NAME column, to its full and more meaningful path, the
+	readlink(2) system call used to do the conversion failed.  The
+	readlink(2) failure message is ``xxx''.
+
+	This situation usually occurs if the lsof process lacks
+	permission to readlink(2) some part of the path -- e.g., the
+	lsof executable lacks root permission, or lsof is attempting to
+	stat(2) a path on an NFS device mounted with the root_squash
+	option.
+
+	The message can be suppressed with lsof's ``-w'' option.
+
+10.6	Why is ``NOFD'' reported as a Linux file type?
+
+	When lsof lacks permission to use opendir() on the fd/
+	subdirectory of a process' /proc/<PID> directory, it reports a
+	single file of the type ``NOFD'' (for no file descriptors).
+
+	Lsof reports the the /proc/<PID>/path in the NAME column,
+	followed by "(opendir: xxx)", where ``xxx'' is the error
+	message returned by opendir().
+
+	The ``NOFD'' entry can be suppressed with lsof's ``-w'' option.
+
+10.7    Why does Linux lsof report a NAME column value that begins with
+	``/proc''?
+
+	When lsof has problems processing a ``/proc/<PID>'' entry --
+	e.g., it can't convert the entry to a full and more meaningful
+	path name, or it can't access the /proc/<PID>/fd subdirectory
+	with opendir() -- it will report the /proc/<PID> path in the
+	NAME column.
+
+10.8	Linux /proc/net/tcp* and /proc/net/udp* issues
+
+10.8.1	Why use the Linux -X option?
+
+	If you're not interested in TCP/IP socket information for a
+	particular use of lsof, adding the -X option will make lsof run
+	more quickly, because -X inhibits the reading of the
+	/proc/net/tcp* and /proc/net/udp* files.  For example, you may
+	only be interested in knowing what process has a particular
+	file open.
+
+	When the Linux system has a large number of open TCP/IP socket
+	files, the time savings provided by -X can be significant.
+
+10.8.2	Why does lsof say ``-i is useless when -X is specified''?
+
+	If -X is specified, lsof can't report much information on open
+	TCP/IP socket files.  However, lsof's -i option requests that
+	information.  Hence, the two options conflict and can't be used
+	together.
+
+10.8.3	Why does lsof say ``can't identify protocol (-X specified)''?
+
+	If the Linux lsof -X option is specified and an open socket
+	file can't be identified without accessing the /proc/net/tcp*
+	and /proc/net/udp* files, lsof will report that it can't
+	identify the socket's protocol and that the failure may be
+	caused by the -X specification
+
+
+11.0	NetBSD Problems
+
+11.1	Why doesn't lsof report on open kernfs files?
+
+	Lsof doesn't report on open NetBSD kernfs files because the
+	structures lsof needs aren't defined in the kernfs.h header
+	file in /sys/misc/kernfs.
+
+11.2	Why doesn't lsof report on open files on: file descriptor
+	file systems; /proc file systems; 9660 (CD-ROM) file systems;
+	MS-DOS (floppy disk) file systems; or kernel file systems?
+
+	Lsof is not able to report on open files on certain file
+	system if /usr/src/sys/msdosfs didn't exist when the lsof
+	Configure script ran and lsof was made.  /usr/src/sys/msdosfs
+	contains header files lsof needs for collecting data on
+	certain file system files.
+
+	You can tell if an lsof executable above) lacks support
+	for a file system if the following test of `lsof -v` produces
+	nothing:
+
+	    $ lsof -v 2>&1 | grep <support_enabled_definition>
+	
+	The <support-enabled_definition> will be:
+
+	    File System Type	Definition	Note
+	    ----------------	----------	----
+	    File descriptor	HASFDESCFS
+	    /proc		HASPROCFS
+	    9660		HAS9660FS
+	    MS-DOS		HASMSDOSFS	(lsof 4.61 and above)
+	    Kernel		HASKERNFS
+
+	The work-around is to install /usr/src/sys, rerun the lsof
+	Configure script, and remake lsof.
+
+11.3    Why does lsof produce confusing results for nullfs file
+	systems?
+
+	Consider this report from /sbin/mount:
+
+	    /usr/home on /home type null (local)
+
+	(According to /sbin/mount /usr/home is the mounted-on device
+	and /home is the mounted-on directory.)
+
+	When lsof is asked to report on open files on /home, it
+	will report them as files on /usr/home instead.  That's an
+	artifact of the NetBSD kernel's dynamic name lookup cache
+	(DNLC) and the way the kernel handles nullfs mounted-on
+	directories.
+
+	While lsof will report all open files on /home when given
+	/home as a file system directory argument, even though
+	reporting them as located on /usr/home, lsof will not find
+	the same files when asked to report on all open files on
+	/usr/home when given /usr/home as a file system device
+	argument.  That's because from the mount perspective
+	/usr/home is equivalent to a device, but from the device
+	perspective it is still a directory.
+
+	So, what this lsof command reports:
+
+	    $ lsof /home
+	    ... NAME
+	    ... /usr/home/...
+
+	Won't be duplicated by this lsof command:
+
+	    $ lsof /usr/home
+
+	Another way to look at this confusing /home and /usr/home
+	example is to consider what stat(2) reports.  For /home
+	stat(2) reports a device doublet that matches what lsof
+	finds in open file node structures, while the device doublet
+	stat(2) reports for /usr/home won't match what lsof finds.
+	Nor does the mode reported by stat(2) indicate a block
+	devices, as is the expected case.
+
+	There is no simple answer to this confusion, nor is there
+	even a simple explanation.  Simply be aware that when
+	supplying file system arguments to lsof on NetBSD, use the
+	mounted-on directory name for a nullfs as the lsof argument,
+	and don't be surprised when the NAME column reports the
+	mounted-on device name.
+
+11.4	NetBSD header file problems
+
+11.4.1	Why can't the compiler find some NetBSD header files?
+
+	If the compiler's pre-processor complains it can't find some
+	header files when it compiles lsof source files, /usr/include
+	and /usr/src may not have all the header files lsof needs.
+
+	As a work-around use the NETBSD_SYS environment variable
+	to specify to lsof the location of the additional header
+	files -- e.g.,
+
+	    % setenv NETBSD_SYS /my_source
+	    % ./Configure -n netbsd
+	
+	 or
+	     $ NETBSD_SYS=/mys_source ./Configure -n netbsd
+
+	Caution: using this work-around may cause the lsof Configure
+	script to activate or omit different features, depending
+	on where it finds the header files that determine the state
+	of the features.
+
+11.4.2	Why does NetBSD lsof produce incorrect output?
+
+	If the NetBSD system's kernel was built from header files that
+	don't match those in /usr/include -- e.g., //usr/src has the
+	ones from which the kernel was built -- lsof may build, but
+	won't produce correct output.
+
+	As a possible work-around, try directing the C compiler to
+	select header files from /usr/src before it selects them from
+	/usr/include.  That can be done with the DEBUG make string --
+	e.g.,
+
+	    $ make DEBUG="-I/usr/src -I/usr/include"
+	
+	If that work-around fails, try using the LSOF_INCLUDE and
+	NETBSD_SYS environment variables to swap /usr/include and
+	/usr/src when running the Configure script, then use the make
+	DEBUG string when running make -- e.g.,
+
+	    $ LSOF_INCLUDE=/usr/src; export LSOF_INCLUDE
+	    $ NETBSD_SYS=/usr/include; export NETBSD_SYS
+	    $ ./Configure -n netbsd
+	    $ make DEBUG="-I/usr/src -I/usr/include"
+
+11.5	Why isn't lsof feature xxx enabled for NetBSD?
+
+	Lsof's Configure script enables NetBSD features by locating
+	and examining header files associated with the features,
+	and based on what it finds, setting compile-time definitions
+	in Makefiles.  (See 00PORTING for a list of the definitions.)
+
+	When Configure doesn't find header files or doesn't find
+	appropriate values in header files, that may mean the header
+	file tree lsof is searching is incomplete or out of date.
+
+	Lsof normally looks for NetBSD header files in /usr/include.
+	It can also be directed to look in other directories --
+	e.g., /sys -- if told to do so with the contents of the
+	LSOF_INCLUDE and NETBSD_SYS environment variables.
+
+	To determine what header file enables a missing feature,
+	check the NetBSD stanza in the Configure script.  Then
+	check the locations it checks for the indicated header
+	files and contents.
+
+	See 00XCONFIG for more information on LSOF_INCLUDE and
+	and NETBSD_SYS.
+
+
+12.0	NEXTSTEP and OPENSTEP Problems
+
+12.1	Why can't lsof report on 3.1 lockf() or fcntl(F_SETLK)
+	locks?
+
+	Lsof has code to test for locks defined with lockf() or
+	fcntl(F_SETLK) under NEXTSTEP 3.1, but that code has never
+	been tested.  I couldn't test it, because my NEXTSTEP 3.1
+	lockf() and fcntl(F_SETLK) functions return "Invalid
+	argument" every way I have tried to invoke them.
+
+	If your NEXTSTEP 3.1 system does allow you to use lockf()
+	and fcntl(F_SETLK) and lsof doesn't report locks set with
+	them, then the code in .../dialects/next/dnode.c probably
+	isn't correct.  Please contact me via e-mail at <abe@purdue.edu>
+	and tell me how you got your lockf() and fcntl(F_SETLK) system
+	calls to work.  Make sure "lsof" appears in the "Subject:" line
+	so my e-mail filter won't classify your letter as Spam.
+
+12.2	Why doesn't lsof compile for NEXTSTEP with AFS?
+
+	I no longer have a NEXTSTEP test system that has AFS.
+	Changes to lsof since I once had a test system have caused
+	me to change the AFS code in NEXTSTEP without being able
+	to test the changes.
+
+	If you need AFS support for NEXTSTEP and can't get it to
+	compile, please contact me.  Perhaps we can jointly fix
+	the problems.
+
+
+13.0	OpenBSD Problems
+
+13.1	Why doesn't lsof support kernfs on my OpenBSD system?
+
+	Lsof supports the kernel file system on OpenBSD versions
+	whose /sys/miscfs/kernfs/kernfs.h (or <miscfs/kernfs/kernfs.h>
+	header file correctly defines the kern_target structure.
+	The lsof Configure script's openbsd stanza checks for the
+	presence of the structure's kt_name element and activates
+	kernfs support for the CFLAGS -DHASKERNFS definition only
+	when it finds kt_name.
+
+	The kernfs.h header file is scheduled to be updated in the
+	OpenBSD 2.1 release, according to Kenneth Stailey, who
+	authored its changes.
+
+13.2	Will lsof work on OpenBSD on non-x86-based architectures?
+
+	I've not tested lsof on an OpenBSD system that uses a
+	non-x86-based architecture, but I've had one report that
+	lsof 4.33 compiles and works on OpenBSD for the pmax
+	architecture (decstation 3100).
+
+13.3	<sys/pipe.h> problems
+
+13.3.1	Why does the compiler claim nbpg isn't defined?
+
+	When compiling lsof on some (older) OpenBSD SPARC versions,
+	the compiler may complain:
+
+	    In file included from ../dlsof.h:191,
+	         from ../lsof.h:166,
+	         from fino.c:52:
+	    /usr/include/sys/pipe.h:83: `nbpg' undeclared here
+					(not in a function)
+	    /usr/include/sys/pipe.h:83: size of array `ms' has
+					non-integer type
+
+	This happens because <sys/pipe.h> uses NBPG from
+	<machine/param.h> to size the `ms' array, and some OpenBSD
+	systems define NBPG in terms of a kernel integer variable,
+	nbpg.
+
+	Lsof revisions 4.46 and above have a hack to dlsof.h,
+	developed by Volker Borchert that avoids the compiler
+	problem for SPARC OpenBSD 2.3.  The hack might work for
+	other OpenBSD SPARC versions, but hasn't been tested there.
+
+	If you want to enable the hack for your OpenBSD SPARC
+	version, modify this code in .../dialects/n+obsd/dlsof.h:
+
+	    # if    defined(OPENBSDV)
+	    #  if   OPENBSDV==2030 && defined(__sparc__)
+	    #   if  defined(nbpg)
+	    #undef  nbpg
+	    #   endif       /* defined(nbpg) */
+	    #define nbpg    4096            /* WARNING!!!  ... */
+	    #  endif        /* OPENBSDV==2030 && defined(__sparc__) */
+	    #include <sys/pipe.h>
+	    #endif  /* defined(OPENBSDV) */
+
+	You will probably want to change the second #if test to
+	match your OpenBSD version.  You may also want to change
+	what value is assigned to nbpg.  See the next section,
+	"What value should I assign to nbpg?"
+
+13.3.2	What value should I assign to nbpg?
+
+	If you need to enable the nbpg hack, described in "Why does
+	the compiler claim nbpg isn't defined?", you may also need
+	to assign a value other than 4096 to nbpg.  4096 works for
+	the sun4c processor and should work for sun4m, but 8192
+	may be needed for sun4.
+
+	Check <machine/param.h> and other OpenBSD documentation to
+	determine the correct nbpg assignment.
+
+13.4	Why doesn't lsof report on open MS-DOS file system (floppy
+	disk) files?
+
+	Lsof is not able to report on open MS-DOS file system files
+	if /usr/src/sys/msdosfs didn't exist when the lsof Configure
+	script ran and lsof was made.  /usr/src/sys/msdosfs contains
+	header files lsof needs for collecting data on MS-DOS file
+	system files.
+
+	You can tell if an lsof executable (revisions 4.61 and
+	above) lacks MS-DOS file system support if the following
+	command reports nothing:
+
+	    $ lsof -v 2>&1 | grep HASMSDOSFS
+
+	The work-around is to install /usr/src/sys, rerun the lsof
+	Configure script, and remake lsof.
+
+13.5	Why isn't lsof feature xxx enabled for OpenBSD?
+
+	Lsof's Configure script enables OpenBSD features by locating
+	and examining header files associated with the features,
+	and based on what if finds, setting compile-time definitions
+	in Makefiles.  (See 00PORTING for a list of the definitions.)
+
+	When Configure doesn't find header files or doesn't find
+	appropriate values in header files, that may mean the header
+	file tree lsof is searching is incomplete or out of date.
+
+	Lsof normally looks for OpenBSD header files in /usr/include
+	and /sys.  It can also be directed to look in other
+	directories if told to do so with the contents of the
+	LSOF_INCLUDE and NETBSD_SYS environment variables.
+
+	To determine what header file enables a missing feature,
+	check the OpenBSD stanza in the Configure script.  Then
+	check the locations it checks for the indicated header
+	files and contents.
+
+	See 00XCONFIG for more information on LSOF_INCLUDE and
+	and NETBSD_SYS.
+
+
+14.0	Output Problems
+
+14.1	Why do the lsof column sizes change?
+
+	Lsof dynamically sizes its output columns each time it runs
+	to make sure that each column takes the minimum space.
+	Column parsing -- e.g., with awk -- is possible, because
+	each column is guaranteed to be separated from the preceding
+	one by at lease one space, and no column except the last
+	(NAME) contains embedded spaces.
+
+14.2	Why does the offset have ``0t' and ``0x'' prefixes?
+
+	The offset value that appears in the SIZE/OFF column has
+	``0t' and ``0x'' prefixes to distinguish it from size values
+	that may appear in the same column.
+
+	Normally if the offset value is less than 100,000,000 (8
+	digits), it appears in decimal with a ``0t' prefix; over
+	99,999,999, in hexadecimal with a ``0x'' prefix.
+
+	A decimal offset is handy, for example, when tracking the
+	progress of an outbound ftp transfer.  When lsof reports
+	on the ftp process, it will report the size of the file
+	being sent with its open descriptor; it will report the
+	progress of the transfer via the offset of the outbound
+	open ftp data socket descriptor.
+
+	The ``-o [n]'' option may be used to specify the maximum
+	number of decimal digits to be printed after ``0t'' before
+	lsof switches to the hexadecimal digits after `0x''.  As
+	already noted, the default decimal digit count is 8.
+
+14.3	What are the values printed in the FILE_FLAG column
+	and why is 0x<value> sometimes included?
+
+	The two comma separated lists, separated by a semicolon,
+	printed in the FILE-FLAG column (when the "+fg" option is
+	specified), are short-hand names or hexadecimal values for
+	the bits lsof finds in the f_flag or f_flags member of file
+	structures for files (the first list, the one before the
+	semicolon), and process open files flags found in various
+	kernel structures, often named "pofile" (the second list,
+	the one after the semicolon).
+
+	Lsof determines the short-hand names from symbols in the
+	<fcntl.h>, <linux/fs.h>, <sys/fcntl.h>, <sys/fcntlcom.h>,
+	o<sys/file.h>, and <sys/user.h> header files.
+
+	See the discussion of FILE-FLAG in the OUTPUT section of
+	the lsof man page, and the FF_* and POF_* symbols in lsof.h
+	for a list of the names.
+
+	Bits with no names defined for them are represented by an
+	0x<value> member of the comma-separated list -- a hexadecimal
+	integer.  When "+fG" is specified (instead of "+fg"), lsof
+	will list all flag values as two hexadecimal integers,
+	separated by a semicolon.
+
+	When "-FG" is specified to get the flags in an output field,
+	the format defaults to hexadecimal.  You can get names
+	instead by following "-FG" with "+fg" -- e.g.,
+
+	    $ lsof -FG +fg ...
+
+	However, when you precede "-FG" with "+fg" -- e.g.,
+	
+	    $ lsof +fg -FG
+	    
+	the format will be hexadecimal; order is important.
+
+14.3.1	Why doesn't lsof display FILE_FLAG values for my dialect?
+
+	All versions of lsof except the /proc-based Linux lsof
+	report FILE-FLAG values.  Lsof can't obtain FILE-FLAG
+	information from the Linux /proc interface.
+
+14.4	Network Addresses
+
+14.4.1	Why does lsof's -n option cause IPv4 addresses, mapped to
+	IPv6, to be displayed in IPv6 notation?
+
+	When you use the -n option to tell lsof to display numeric
+	network addresses, and an IPv4 address has been mapped to
+	IPv6, lsof displays the address in IPv6 format and puts
+	"ipv4" in the TYPE column.  That combination indicates the
+	IPv4 address has been mapped to IPv6.
+
+	For example, the IPv4 address 1.2.3.4, when mapped to an
+	IPv6 address, will be displayed by lsof as:
+
+	    [::ffff:1.2.3.4]
+	
+	The enclosing brackets are lsof's signal that this is an
+	IPv6 address.  Inside the brackets is a standard IPv6
+	address, reported by inet_ntop().  The first two colons,
+	signifying zeroes in the first 64 bits of the IPv6 address,
+	and the hexadecimal ffff in the next 32 bits, indicate that
+	the last 32 bits contains a mapped IPv4 address, which is
+	then displayed in IPv4 dot notation.
+
+14.5	Why does lsof output \x, ^x, or \xnn for characters
+	sometimes?
+
+	Lsof displays only printable ASCII characters.  Lsof
+	considers a character printable if isprint(3) says it
+	is.  If isprint(3) says a character isn't printable,
+	the lsof may page explains:
+
+	   "...  Non-printable characters are printed in one of
+	    three forms: the C ``\[bfrnt]'' form; the control
+	    character `^' form (e.g., ``^@''); or hexadecimal
+	    leading ``\x'' form (e.g., ``\xab'').  Space is
+	    non-printable in the COMMAND column (``\x20'') and
+	    printable elsewhere."
+
+14.5.1  Why is space considered a non-printable character in command
+	names?
+
+	Space is considered an unprintable character in command
+	names because it is sometimes possible to hide the full
+	command name from scripts that parse ps(1) output by
+	embedding a space in the name.
+
+14.6	Why doesn't lsof print all the characters of a command name?
+
+	By default lsof prints the first nine characters of the
+	names of commands associated with processes.  If more
+	characters are required, the "w" value of the "+c w" option
+	may be used to specify a larger width.
+	
+	If "w" is zero ('0') lsof will print all characters of all
+	command names up to the limit of the number of characters
+	supplied by the particular UNIX dialect.  When reporting
+	command names, lsof replaces non-printable characters as
+	discussed in the answer to " Why does lsof output \x, ^x, or
+	\xnn for characters sometimes?"
+
+	See the answer to the "Why is space considered a non-printable
+	character in command names?" question for an explanation of why
+	spaces are replaced by the ``\x20'' representation in command
+	names.
+
+	The number of command name characters supplied to lsof by UNIX
+	dialects in files and structures varies by dialect.  For
+	example, Linux 2.4.27 supplies lsof the first 15 characters of
+	command names and Solaris 9 supplies 16.  Thus, even if "w" is
+	zero ('0'), lsof can't report more characters for command names
+	on those two UNIX dialects than they provide lsof.
+
+14.7	Why does lsof reject some -c command names, saying their lengths
+	are "> what system provides (nn)"?
+
+	The command name length that a specific system provides varies
+	from dialect to dialect.  As noted in the answer to the "Why
+	doesn't lsof print all the characters of a command name?"
+	question, Linux and Solaris provide a limited number of command
+	name characters.
+
+	When more characters are specified in the parameter to the -c
+	option, lsof considers it an error and issues a fatal error
+	message -- e.g.,
+
+	   lsof: "-c xxxxyyyy" length (8) > what system provides (7)
+
+	The only work-around is to specify no more characters to -c
+	that the system provides to lsof.
+
+14.8	Why does lsof sometimes print TYPE numbers instead of names?
+
+	When lsof can't convert a type number to a name for printing in
+	the TYPE column, it will report the number as four octets.
+
+14.9	Marker line format problems
+
+14.9.1	Why won't lsof accept a marker line format?
+
+	Lsof's Configure script must find the localtime(3) and
+	strftime(3) functions in the dialect's C library in order to
+	enable support for marker line formats.
+
+	Check the output of lsof's -v option for the presence of
+	-DHAS_STRFTIME in the compiler flags.  If it isn't there,
+	Configure didn't find the necessary two C library functions.
+
+	If you think lsof should have found the functions, make a copy
+	of the C test program in the Configure script that it uses to
+	find the functions.  Then use the copy, or a more informative
+	modification of it, to learn why Configure can't find the
+	functions.  You can find that program by searching for
+	strftime.
+
+14.9.2	Why does lsof reject the NL (%n) marker line format?
+
+	When repeat mode and field output (with -F) have both been
+	specified, lsof won't allow new line (NL) formats to be
+	specified with ``%n''.  That's because the marker line is
+	always guaranteed to be a single line.
+
+	There is no work-around to this restriction.
+
+14.10	How are protocol state name exclusion and inclusion used?
+
+	Protocol state name inclusion and exclusion with the ``-s p:s''
+	option and its arguments have some issues to consider.  Note:
+	the ``-s p:s'' option is only available when the help output,
+	obtained with -h or -?, shows it; it was a recent addition to
+	lsof and is supported only on dialects where it could be
+	tested.
+
+	First, there is the problem of determining what state names, if
+	any, the dialect produces.  Try running this lsof command to
+	find them:
+
+	    $ lsof -i
+
+	Knowing the state names of interest, the next problem is to
+	decide on the lsof options and their parameters that will
+	produce the desired output.  Here some examples are probably
+	the most useful.
+
+	To list only TCP socket files in LISTEN and CLOSE_WAIT states,
+	use:
+
+	    $ lsof -itcp -stcp:listen,close_wait
+	or
+	    $ lsof -iTCP -sTCP:LISTEN,CLOSE_WAIT
+
+	Case isn't important to lsof in protocol and state names.
+
+	To exclude TCP socket files in CLOSE_WAIT state, use:
+
+	    $ lsof -itcp -stcp:^close_wait
+
+	Note the `^' preceding close_wait; it selects exclusion.  You
+	can mix included and excluded names in a comma separated list,
+	but you may not include and exclude the same name for the same
+	protocol.
+
+	To list TCP files in LISTEN state and UDP files in Idle state,
+	use:
+
+	    $ lsof -i -stcp:listen -sudp:idle
+
+	Note: if you don't accompany the ``-s p:s'' list option and
+	argguments with the -i option, lsof will list all other regular
+	files, while applying the specified inclusion and exclusion
+	specifications to network files.  Generally, then, you want to
+	use -i with -s.
+
+14.10.1	Why doesn't my dialect support state name exclusion and inclusion?
+
+	When state name inclusion and exclusion was added, I had access
+	to test systems for AIX, Darwin, FreeBSD, Linux, PSTAT-based
+	HP-UX and Solaris.
+
+	Therefore, I was unable to add and test the support to any other
+	UNIX dialects.
+
+	If a dialect has the support, then the HASTCPUDPSTATE definition
+	in its machine.h header file will be active; if not, it will be
+	absent or commented out.
+
+	If your dialect doesn't have the support and you want it added,
+	you will have to provide me Internet access to a test host, where
+	I can compile lsof and have the credentials to test the changes
+	the support requires.  If that's possible for you, please contact
+	me via e-mail at <abe@purdue.edu>.  Make sure "lsof" appears in
+	the "Subject:" line so my e-mail filter won't classify your letter
+	as Spam.
+
+
+15.0	Pyramid Version Problems
+
+15.0.5	Statement of deprecation
+
+	As of lsof revision 4.52 support for all Pyramid versions has
+	been dropped.  Contact me via e-mail at <abe@purdue.edu> if you
+	are interested in obtaining the last lsof Pyramid distribution.
+	Make sure "lsof" appears in the "Subject:" line so my e-mail
+	filter won't classify your letter as Spam.
+
+
+16.0	SCO Problems
+
+16.1	SCO OpenServer Problems
+
+16.1.1	How can I avoid segmentation faults when compiling lsof?
+
+	If you have an older SCO OpenServer compiler, it may get
+	a segmentation fault when compiling some lsof modules.
+	That appears to happen because of the -Ox optimization
+	action requested in the lsof Makefile.
+
+	Try changing -Ox to -O with this make invocation:
+
+	    $ make DEBUG=-O
+
+	Bela Lubkin supplied this tip and Steve Williams verified
+	it.
+
+16.1.2	Where is libsocket.a?
+
+	If you compile lsof and the loader says it can't find the
+	socket library, libsocket.a, called by the -lsocket option
+	in the lsof compile flags, you probably are running an SCO
+	OpenServer release earlier than 5.0 and don't have the
+	TCP/IP Development System package installed.
+
+	You may have the necessary header files, because you have
+	the TCP/IP run-time package installed, but if you don't
+	have the TCP/IP Development System package installed, you
+	won't have libsocket.a.
+
+	Your choices are to install the TCP/IP Development System
+	package or upgrade to OpenServer Release 5.0.  You will
+	find libsocket.a in 5.0 -- you'll find all the libraries
+	and header files there, in fact -- and you can use gcc to
+	compile lsof if you don't want to install the 5.0 Development
+	System package.
+
+16.1.3	Why do I get "warning C4200" messages when I compile lsof?
+
+	When you compile lsof under OSR 3.2v4.2 (and perhaps under
+	earlier versions as well), you may get many compiler warning
+	messages of the form:
+
+	    node.c(183) : warning C4200: previous declarator is not
+	    compatible with default argument promotion
+
+	In my opinion this is a bug in the OSR compiler.  Because
+	the compiler cannot handle full ANSI-C prototypes, it
+	assumes default types for function parameters as it encounters
+	untyped in a function prototype -- e.g., in this function
+	declaration from node.c,
+
+	    readrnode(ra, r)
+		KA_T ra;
+		struct rnode *r;
+	    {
+	    ...
+	
+	the compiler assigns default int types to the ra and r
+	arguments.
+
+	Then, when the compiler encounters the fully typed parameters
+	after the function skeleton and sees parameters with types
+	that don't match the assumptions it previously made, it
+	whines about its own assumptions.
+
+	You can ignore these messages.
+
+16.2	SCO|Caldera UnixWare Problems
+
+16.2.1  Why doesn't lsof compile on my UnixWare 7.1.1 or above
+	system?
+
+	When you Configure lsof with the "uw" abbreviation and try
+	to compile it for UnixWare 7.1.1, you may get compiler
+	error messages like this:
+
+	    UX:acomp: ERROR: "dproc.c", line 98:
+		undefined struct/union member: p_pgidp
+
+	This suggest that you probably have a non-stop cluster
+	UnixWare 7.1.1 system.  Its <sys/proc.h> header file differs
+	from the one on the system where I did the lsof port to
+	UnixWare 7.1.1.  I currently don't have access to a non-stop
+	cluster system to be able to develop changes to lsof that
+	would make it compile and work there.
+
+	If you have a non-stop cluster UnixWare 7.1.1 system, want lsof
+	for it, and can offer me a test account on the system, please
+	contact me via e-mail at <abe@purdue.edu>.  Make sure "lsof"
+	appears in the "Subject:" line so my e-mail filter won't
+	classify your letter as Spam.
+
+	If you have a system with nsc_cfs and can offer me a test
+	account on it, please contact me via e-mail at <abe@purdue.edu>.
+	Make sure "lsof" appears in the "Subject:" line so my e-mail
+	filter won't classify your letter as Spam.
+
+16.2.2  Why does lsof complain about node_self() on my UnixWare
+	7.1.1 or above system?
+
+	If lsof exits immediately after issuing this message:
+
+	    can't identify process NSC node; node_self(): <message>
+
+	It means that lsof has been built to run on a NonStop
+	Cluster (NSC) UnixWare 7.1.1 or higher system and can't
+	get the number of the node on which it is running.  Lsof
+	uses the node number to determine the path to the kernel
+	boot file.
+
+	You can tell if lsof has been built for NSC by looking for
+	"-DHAS_UW_NSC" in lsof's "-v" option output.
+
+	If the system on which you're trying to run lsof isn't
+	running an NSC kernel, you will need to build a non-NSC
+	lsof.
+
+16.2.3  Why does UnixWare 7.1.1 or above complain about -lcluster,
+	node_self(), or libcluster.so?
+
+	When you build, compile, and load lsof for UnixWare 7.1.1
+	and above, ld may complain that it can't find the -lcluster
+	library or that the node_self symbol is undefined.  When
+	you try to run an existing lsof binary it may complain that
+	libcluster.so can't be found.
+
+	These messages mean the tests made by Configure on your
+	system led it to believe your system is running a NonStop
+	Cluster (NSC) kernel, or the lsof binary you're trying to
+	use was built on a NonStop Cluster system.  If an lsof
+	binary was built for NSC, this shell command produces
+	output:
+
+	    $ strings <lsof_binary> | grep HAS_UW_NSC
+
+	If that's not the case, and you can rebuild lsof, set the
+	UW_HAS_NSC environment variable to "N" and do this:
+
+	   $ Configure -n clean
+	   $ UW_HAS_NSC=N
+	   $ export UW_HAS_NSC
+	   $ Configure -n uw
+	   $ make
+
+	You can also edit Makefile and lib/Makefile.  Remove
+	-DHAS_UW_NSC from the CFGF strings.  Remove -lcluster from
+	the CFGL strings.  Then run make again.
+
+	If you have an existing NSC lsof binary and you want one
+	for a non-NSC system, you will have to build lsof yourself
+	on the system where you want to use it.  (That's always a
+	good idea anyway.)
+
+
+16.2.4  Why does UnixWare 7.1.1 or above lsof complain it can't
+	read the kernel name list?
+
+	If lsof complains:
+
+	    can't read kernel name list from <path>
+
+	It means that lsof can't find the booted kernel image file
+	at <path>.  On NonStop Cluster (NSC) UnixWare 7.1.1 or
+	higher systems lsof determines the booted file path by
+	examining this file:
+
+	    /stand/`node_self`/boot
+
+	If examining that file doesn't lead to an NSC path, lsof
+	uses:
+
+	    /stand/1/unix
+
+	On non-NSC systems lsof expects the booted kernel image to
+	be in /stand/unix.
+
+	If your booted kernel image is in a different place, use
+	lsof's "-k <path>" option to specify its path.
+
+16.2.5  Why doesn't lsof report link count, node number, and size
+	for some UnixWare 7.1.1 or above CFS files?
+
+	Lsof reports link count, node number, and size for open
+	CFS files as recorded in their kernel node structure's
+	cached attributes.  Sometimes not all attributes are cached
+	on the node where lsof runs, so lsof cannot report them.
+
+16.2.6  Why doesn't lsof report open files on all UnixWare 7.1.1
+	NonStop Cluster (NSC) nodes?
+
+	Lsof can only report on files open on the node on which it
+	runs, because the information lsof reports comes from the
+	private kernel memory of the node.  This may mean that
+	asking lsof to find a specific open file, or use of a
+	specific Internet address or port, may not report all open
+	instances on nodes other than the one used to run lsof.
+
+	You can use the NSC onnode(1) command to run lsof on specific
+	nodes, or the onall(1) command to run lsof on all nodes --
+	e.g.,
+
+	    $ onall lsof [options] 2>&1 | less
+	 or
+	    $ onnode node-number lsof [options] 2>&1 | less
+
+	Note that, when lsof is run all nodes, the path name
+	component assembly results it reports in its NAME column
+	may vary, because the dynamic name cache from which lsof
+	gets the components is private to the kernel of each node.
+
+	Also note the use of shell redirection in the examples to
+	merge the standard error file information from onnode and
+	onall with lsof's standard output file output.  That will
+	put the onnode and onall node announcements in proper
+	sequence with lsof's output.
+
+16.2.7	Why doesn't lsof report the UnixWare 7.1.1 NonStop Cluster
+	(NSC) node a process is using?
+
+	To induce lsof to report the node on which a process runs
+	would be a significant, non-standard modification to lsof.
+	It has much wider implications than merely the printing of
+	a number in an output column.  I'm not currently (April
+	2001) prepared to undertake such a modification.
+
+	If you want node-specific NSC information about open files,
+	run lsof under the control of onall(1) or onnode(1).
+
+	    $ onall lsof [options] 2>&1 | less
+	 or
+	    $ onnode node-number lsof [options] 2>&1 | less
+
+16.2.8  Why does the compiler complain about missing UnixWare 2.1[.x]
+	header files?
+
+	SCO|Caldera didn't ship the following header files with
+	UnixWare 2.1 through 2.1.3:
+
+	    <fs/proc/prdata.h>
+	    <fs/procfs/prdata.h>
+	    <sys/fs/fifonode.h>
+	    <sys/fs/namenode.h>
+
+	Lsof needs those header files for its compilation.  Contact
+	SCO|Caldera to get copies of those header files.
+	
+	If you can't get the header files from SCO|Caldera, please
+	contact me via e-mail at <abe@purdue.edu>.  Make sure "lsof"
+	appears in the "Subject:" line so my e-mail filter won't
+	classify your letter as Spam.
+
+
+17.0	Sun Problems
+
+17.0.5	Statement of deprecation
+
+	Lsof support for SunOS 4.1.x was last tested at revision 4.51.
+	Contact me via e-mail at <abe@purdue.edu> if you're interested in
+	obtaining it.  Make sure "lsof" appears in the "Subject:" line so
+	my e-mail filter won't classify your letter as Spam.
+
+17.1	My Sun gcc-compiled lsof doesn't work -- why?
+
+	Gcc can be used to build lsof successfully.  However, an
+	improperly installed Sun gcc compiler will usually not
+	produce a working lsof.
+
+	If your Sun gcc-compiled lsof doesn't report anything, or
+	reports ``can't read proc table,'' or gcc refuses to compile
+	lsof without error, check that the gcc step that "fixes"
+	Sun header files was run on the system where you're using
+	gcc to compile lsof.  As an alternative, if you have the
+	SunPro C 5.0 compiler or later available, use it to compile
+	lsof -- e.g., use the solariscc Configure abbreviations.
+
+17.2	How can I make lsof compile with gcc under Solaris 2.[456],
+	2.5.1, 7, 8 or 9?
+
+	Presuming your gcc-specific header files are wrong for
+	Solaris, edit the lsof Configure-generated Makefile and
+	lib/Makefile and make this change:
+
+		CFGF=   -Dsolaris=20400 ...
+	to
+		CFGF=   -Dsolaris=20400 -D__STDC__=0 -I/usr/include ...
+
+	or change:
+
+		CFGF=   -Dsolaris=20500 ...
+	to
+		CFGF=   -Dsolaris=20500 -D__STDC__=0 -I/usr/include ...
+
+	or change:
+
+		CFGF=   -Dsolaris=20501 ...
+	to
+		CFGF=   -Dsolaris=20501 -D__STDC__=0 -I/usr/include ...
+
+	This is only a temporary work-around.  You really should
+	instruct gcc to to update your gcc-specific header files
+	or install a recent gcc (e.g., 3.2), which has no need for
+	private copies of Solaris include files.
+
+17.3	Why does Solaris Sun C complain about system header files?
+
+	You're probably trying to use /usr/ucb/cc if you get compiler
+	complaints like:
+
+	    cc -O -Dsun -Dsolaris=20300 ...
+	    "/usr/include/sys/machsig.h", line 81: macro BUS_OBJERR
+	    redefines previous macro at "/usr/ucbinclude/sys/signal.h",
+	    line 444
+
+	Note the reference to "/usr/ucbinclude/sys/signal.h".  It
+	reveals that the BSD Compatibility Package C compiler is
+	in use.  Lsof requires the ANSI C version of the Solaris
+	C compiler, usually found in /usr/opt/bin/cc or
+	/opt/SUNWspro/bin/cc.
+
+	Try adding a CC string to the lsof Makefile that points to
+	the Sun ANSI C version of the Sun C compiler -- e.g.,
+
+	    CC= /usr/opt/bin/cc
+	or
+	    CC= /opt/SUNWspro/bin/cc.
+
+17.4	Why doesn't lsof work under my Solaris 2.4 system?
+
+	If lsof doesn't work under your Solaris 2.4 system -- e.g.,
+	it produces no output, little output, or the output is
+	missing command names or file descriptors -- you may have
+	a pair of conflicting Sun patches installed.
+
+	Solaris patch 101945-32 installs a kernel that was built
+	with a <sys/auxv.h> header file whose NUM_*_VECTORS
+	definitions don't match the ones in the <sys/auxv.h> updated
+	by Solaris patch 102303-02.
+
+	NUM_*_VECTORS in the kernel of patch 101945-32 are smaller
+	than the ones in the <sys/auxv.h> of patch 102303-02.  The
+	consequence is that when lsof is compiled with the <sys/auxv.h>
+	whose NUM_*_VECTORS definitions are larger than the ones
+	used to compile the patched kernel, lsof's user structure
+	does not align with the one that the kernel employs.
+
+	If you have these two patches installed, contact Sun and
+	complain about the mis-match.
+
+	You may be able to work around the problem by editing
+	/usr/include/sys/auxv.h to have the following NUM_*_VECTORS
+	definitions:
+
+		    #define NUM_GEN_VECTORS 4
+		    #define NUM_SUN_VECTORS 8
+	
+	The Configure script issues a prominent WARNING that you should
+	try the work-around.
+
+	I thank Leif Hedstrom for identifying the offending patches.
+
+17.5	Where are the Solaris header files?
+
+	If you try to compile lsof under Solaris and get a compiler
+	complaint that it can't find system header files, perhaps
+	you forgot to add the header file package, SUNWhea.
+
+17.6	Where is the Solaris /usr/src/uts/<architecture>/sys/machparam.h?
+
+	When you try to Configure lsof for Solaris 2.[23456], 2.5.1,
+	and 7 -- e.g., on a `uname -m` == sun4m system -- Configure
+	complains:
+
+	    grep: /usr/src/uts/sun4m/sys/machparam.h:
+			No such file or directory
+	    grep: /usr/src/uts/sun4m/sys/machparam.h:
+			No such file or directory
+
+	And when you try to compile the configured lsof, cc or gcc
+	complains:
+
+	    dproc.c:530: `KERNELBASE' undeclared (first use this function)
+
+	The explanation is that somehow your Solaris system doesn't
+	have the header files in /usr/src/uts it should have.  Perhaps
+	someone removed the directory to save space.  Perhaps you're
+	using a gcc installation, copied from another system.  In any
+	event, you will have to load the header files from the SUNWhea
+	package of your Solaris distribution.
+
+	KERNELBASE is an important symbol to lsof -- it keeps lsof
+	from sending an illegal kernel value to kvm_read() where
+	a segmentation violation might result (a bug in the kvm
+	library).  Lsof can get illegal kernel values because it
+	reads kernel values slowly with kvm_read() calls that the
+	kernel is changing rapidly.
+
+	Lsof doesn't need KERNELBASE at Solaris 2.5 and above,
+	because it has a KERNELBASE value whose address lsof can
+	find with /dev/ksyms and whose value it can read with
+	kvm_read().  Under Solaris 2.5 /usr/src/uts has moved to
+	/usr/platform.
+
+17.7	Why does Solaris lsof say ``can't read proc table''?
+
+	When lsof collects data on processes, using the kvm_*()
+	functions to scan the kernel's proc structure table, it
+	checks to make sure it has identified a reasonable number
+	of them -- a minimum of three.  When lsof can't identify
+	three processes during a scan, it repeats the scan.
+
+	When five scans fail to yield three processes, lsof issues
+	the fatal message:
+
+		lsof: can't read proc table
+
+	and exits.
+
+	Usually lsof fails to identify three processes during a
+	scan because its idea of the form of the proc structure
+	differs from that being used by the kernel.  Since the proc
+	structure is defined in <sys/proc.h> and other /usr/include
+	header files, the root cause of a proc structure discrepancy
+	usually can be found in the composition of /usr/include.
+
+	One common way that /usr/include header files can be
+	incorrect is that gcc was used to compile lsof, gcc used
+	its special (i.e., "fixed") header files instead of the
+	ones in /usr/include, and the special gcc header files
+	weren't updated when Solaris was.  Answers to these questions:
+
+	    My Sun gcc-compiled lsof doesn't work -- why?
+
+	    How can I make lsof compile with gcc under Solaris 2.[456],
+	    2.5.1, 7, 8 or 9?
+
+	    Why does Solaris Sun C complain about system header files?
+
+	discuss the gcc header file problem and offer suggestions
+	on how to fix it or work around it.
+
+	It may also be that you are trying to run a version of lsof
+	that was compiled on an older version of Solaris.  For
+	example, an lsof executable, compiled for Solaris 2.4, will
+	produce the ``can't read proc table'' message if you try
+	to run it under Solaris 2.5.  If you have compiled lsof
+	under Solaris 2.5 and it still won't work, see if the header
+	files in /usr/include have been updated to 2.5, or still
+	represent a previous version of Solaris.
+
+	Another source of header file discrepancies to consider is
+	the Solaris patch level and whether a binary kernel patch
+	was not matched with a corresponding header file update.
+	See the "Why doesn't lsof work under my Solaris 2.4 system?"
+	question for an example of one in Solaris 2.4 -- there may
+	be other such patch conflicts I don't know about.
+
+17.8    Why does Solaris lsof complain about a bad cached clone device?
+
+	When lsof revisions below 4.04 have been run on a Solaris
+	system and have been allowed to create a device cache file,
+	the running of revisions 4.04 and above on the same systems
+	may produce this complaint:
+
+	    lsof: bad cached clone device: ...
+	    lsof: WARNING: created device cache file: ...
+
+	This is the result of a change in the device cache file
+	that took place at lsof revision 4.04.  The change introduced
+	a node number into the clone device lines of the device
+	cache file and was done in such a way that lsof could detect
+	device cache files whose clone lines don't have node numbers
+	(lines created by previous lsof revisions) and recognize
+	the need to regenerate the device cache file.
+
+17.9	Why doesn't Solaris make generate .o files?
+
+	Solaris /usr/ccs/bin/make won't generate .o files from .c
+	files if /usr/share/lib/make/make.rules is missing.  It
+	may be found in and installed from the SUNWsport package.
+
+17.10	Why does lsof report some Solaris 2.3 and 2.4 lock types as `N'?
+
+	For Solaris 2.3 with patch P101318 installed at level 45
+	or above, and for all versions of Solaris 2.4, NFS locks
+	are represented by a NFS-specific kernel lock structure
+	that sometimes lacks a read or write lock type indicator.
+	When lsof encounters such a lock structure, it reports the
+	lock type as `N'.
+
+17.11	Why does lsof Configure say "WARNING: no cc in ..."?
+
+	When lsof's Configure script is executed with the solariscc
+	abbreviation it tries to make sure it's using the Sun C
+	compiler and not the UCB substitute from /usr/ucb/cc.
+	Thus, it looks for cc in the "standard" Sun compiler
+	location, /opt/SUNWspro/bin.
+
+	If Configure can't find cc there, it issues the warning:
+
+	    lsof: WARNING: no cc in /opt/SUNWspro/bin;
+		  using cc without path.
+
+	and uses cc for the compiler name, letting the shell find
+	cc with its PATH environment variable.
+
+	You can tell Configure where to find your cc with the
+	SOLARIS_CCDIR cross-configuration environment variable.
+	(See 00XCONFIG for more information on SOLARIS_CCDIR).
+	For example, use this Configure shell command:
+
+	    SOLARIS_CCDIR=/usr/special/bin Configure -n solariscc
+
+	(SOLARIS_CCDIR should be the full path to the directory
+	containing your cc.)
+
+17.12	Solaris 7, 8 and 9 Problems
+
+17.12.1	Why does lsof say the compiler isn't adequate for Solaris
+	7, 8 or 9?
+
+	Solaris 7, 8 and 9 kernels come in two flavors, 32 and 64
+	bit.  64 bit kernels run on machines that support the SPARC
+	v9 instruction set architecture.  Separate executables for
+	some programs, -- e.g., ones using libkvm like lsof -- must
+	be built for 32 and 64 bit kernels.
+
+	Previous Sun (e.g., SC4.0) and earlier gcc compilers will
+	build lsof for 32 bit kernels, but they won't build it for
+	64 bit kernels.  Compilers that will build lsof for 64 bit
+	Solaris 7, 8 and 9 kernels are the Sun WorkShop Compilers
+	C 5.0 and above, and recent gcc versions, e.g., 3.2.
+
+	When given the ``-xarch=v9'' flag, the C 5.0 compiler and
+	above, and associated loader and 64 bit libraries will
+	build a 64 bit lsof executable; when given the "-m64" or
+	"-mcpu=v9" (deprecated) flags, an appropriate gcc compiler
+	will build a 64 bit lsof executable.
+
+	When the lsof Configure script detects a 64 bit kernel is
+	in use (e.g., by executing `/bin/isainfo -kv`), and when
+	it finds that the specified compiler is inappropriate,
+	it complains with these messages:
+
+	For gcc:
+
+	    "!!!WARNING!!!=========!!!WARNING!!!=========!!!WARNING!!!"
+	    "!                                                       !"
+	    "! LSOF NEEDS TO BE CONFIGURED FOR A 64 BIT KERNEL, BUT  !"
+	    "! THIS GCC DOESN'T SUPPORT THE BUILDING OF 64 BIT       !"
+	    "! SOLARIS EXECUTABLES.  LSOF WILL BE CONFIGURED FOR A   !"
+	    "! 32 BIT echo KERNEL.                                   !"
+	    "!                                                       !"
+	    "!!!WARNING!!!=========!!!WARNING!!!=========!!!WARNING!!!"
+	
+	For Sun C:
+
+	  !!!WARNING!!!==========!!!WARNING!!!==========!!!WARNING!!!
+	  !                                                         !
+	  ! LSOF NEEDS TO BE CONFIGURED FOR A 64 BIT KERNEL, BUT    |
+	  ! THE VERSION OF SUN C AVAILABLE DOESN'T SUPPORT THE      !
+	  ! -xarch=v9 FLAG.  LSOF WILL BE CONFIGURED FOR A 32 BIT   !
+	  ! KERNEL.                                                 !
+	  !                                                         !
+	  !!!WARNING!!!==========!!!WARNING!!!==========!!!WARNING!!!
+
+17.12.2 Why does Solaris 7, 8 or 9 lsof say "FATAL: lsof was compiled
+	for..."?
+
+	Solaris 7, 8 or 9 lsof may say:
+
+	    lsof: FATAL: lsof was compiled for a xx bit kernel,
+		  but this machine has booted a yy bit kernel.
+	
+	    Where: xx = 32 or 64
+		   yy = 64 or 32
+	
+	    (xx and yy won't match.)
+	
+	This message indicates that lsof was compiled for one size
+	kernel and is being asked to execute on a different size
+	one.  That's not possible for programs like lsof that use
+	libkvm.
+
+	Depending on the instruction sets for which you need Solaris
+	7, 8 or 9 lsof, you may need two or more versions of lsof,
+	compiled for each kernel size, installed for use with
+	/usr/lib/isaexec.  See the "How do I install lsof for
+	Solaris 7, 8 or 9?" section of this document for more
+	information on that.
+
+17.12.3	How do I build lsof for a 64 bit Solaris kernel under a 32
+	bit Solaris kernel?
+
+	If your Solaris system has an appropriate compiler (e.g.,
+	WorkShop Compilers C 5.0 and above, or a recent gcc like
+	3.2) and the 64 bit libraries have been installed, you can
+	force lsof's Configure script to build a 64 bit version of
+	lsof with:
+
+	    $ SOLARIS_KERNBITS=64 Configure -n solariscc
+	
+	The SOLARIS_KERNBITS environment variable is part of the
+	lsof cross-configuration support, described in the 00XCONFIG
+	file of the lsof distribution.
+
+17.12.4	How do I install lsof for Solaris 7, 8 or 9?
+
+	If you are installing lsof where it will be used only under
+	the bit size kernel for which it was built, no special
+	installation is required.
+
+	If, however, you are installing different versions of lsof
+	for different bit sizes -- e.g., for use on a 64 bit NFS
+	server and from its 32 bit clients -- you should read the
+	man page for isaexec(3C) and install lsof according to its
+	instructions.
+
+	The executable at the directory where lsof is to be found
+	should be a hard link to /usr/lib/isaexec or a copy of it.
+	In the directory there must be instruction architecture
+	subdirectories -- e.g., .../sparc/ and .../sparcv9/.  The
+	lsof for 64 bit size kernels is installed in the .../sparcv9/
+	subdirectory; the one for 32 bit size kernels, in .../sparc/.
+
+	For example, if you're installing 32 and 64 bit lsof
+	executables in /usr/local/etc, you would:
+
+		# cd /usr/local/etc
+		# ln /usr/lib/isaexec lsof
+		# mkdir sparc sparcv9
+		# install the 32 bit lsof as sparc/lsof
+		# install the 64 bit lsof as sparcv9/lsof
+		# chmod, chown, and chgrp sparc/lsof and
+		  sparcv9/lsof appropriately
+
+	Lsof permissions and ownerships are the same whether one
+	or more lsof executables are being installed, with or
+	without the /usr/lib/isaexec hard link.
+
+17.12.5 Why does my Solaris 7, 8 or 9 system say it cannot execute
+	lsof?
+
+	When you attempt to execute lsof, your Solaris 7, 8 or 9
+	shell may complain:
+
+	    ksh: ./lsof: cannot execute
+
+	If the lsof executable exists and has the proper execution
+	permissions, this error may be the result of trying to
+	execute an lsof, built for a 64 bit kernel, on a 32 bit
+	kernel.
+
+	This will tell you about the lsof executable:
+
+	    $ file lsof
+	    lsof: ELF 64-bit MSB executable SPARCV9 Version 1,
+		  dynamically linked, not stripped
+	
+	The "64-bit" notation indicates the binary was built for
+	a 64 bit kernel.  To see the running kernel bit size, use
+	this command:
+
+	    $ isainfo -kv
+	    32-bit sparc kernel modules
+
+	The "32-bit" notation indicates a 32 bit kernel has been
+	booted.
+
+	The only work-around is to obtain, or Configure and make,
+	an lsof for the appropriate kernel bit size.  If you
+	Configure and make lsof on the kernel where you wish to
+	run it the proper compiler, the lsof Configure step will
+	generate Makefiles that can be used with make to build an
+	appropriate lsof executable.
+
+	To compile a 64 bit lsof, you must have an appropriate
+	compiler -- i.e., Sun WorkShop Compilers C 5.0 or higher
+	or a recent gcc like 3.2.
+
+17.12.6 What gcc will produce 64 bit Solaris 7, 8 and 9 executables?
+	8 and 9 executables?
+
+	Properly built and installed recent gcc versions -- e.g.,
+	3.2 -- will build lsof for 64 bit Solaris kernels.
+
+	If you update your gcc version to 3.2 or later, make sure
+	the private gcc header files become current -- i.e., clear
+	out any private header files from a previous gcc or Solaris
+	installation before installing the new ones, or build to
+	a new --prefix root and replace the old root with it after
+	the build and installation are complete.
+
+17.12.7 Why does lsof on my Solaris 7, 8 or 9 system say, "can't
+	read namelist from /dev/ksyms?"
+
+	You're probably trying to use an lsof executable built for
+	an earlier Solaris release on a 64 bit Solaris 7, 8 or 9
+	kernel.  The output from `lsof -v` will tell you the build
+	environment of your lsof executable.  You should also have
+	gotten a warning message that lsof is compiled for a
+	different Solaris version than the one under which it is
+	running -- something like this:
+
+	    lsof: WARNING: compiled for Solaris release X; this is Y
+
+	You need to build lsof on the system where you want to use
+	it.  For 64 bit Solaris 7, 8 and 9 you need a compiler that
+	can generate 64 bit Solaris executables -- e.g., the Sun
+	Workshop 5 C compiler or later, or a recent gcc version
+	like 3.2.  See the "Why does lsof say the compiler isn't
+	adequate for Solaris 7, 8 or 9?" section and the ones
+	following it for a discussion of building lsof for 64 bit
+	Solaris 7, 8 or 9.
+
+17.13	Solaris and COMMON
+
+17.13.1	What does COMMON mean in the NAME column for a Solaris VCHR
+	file?
+
+	When lsof puts COMMON or (COMMON) in the NAME column of a
+	Solaris VCHR file, it means that the file is handled by
+	the special file system functions of the kernel through a
+	common vnode.
+
+17.13.2	Why does a COMMON Solaris VCHR file sometimes seem to have an
+	incorrect minor device number?
+
+	When lsof reports on an open file in a Solaris special file
+	system that uses a COMMON vnode, and the file is a VCHR
+	file, lsof tries to locate the associated device node by
+	looking for matches on the major and minor device numbers
+	first.
+
+	If no major and minor match results, lsof then looks for
+	a match on pseudo and clone device files.  (See /devices/pseudo.)
+	Those device nodes are matched specially by either their
+	major or minor device numbers, but not both.  Hence, when
+	lsof finds a match under those special conditions, it may
+	report a value in its output DEVICE column that differs
+	from one of the major and minor numbers of the device node.
+
+	Here's an example from a sun4m Solaris 7 system:
+
+	    $ ls -li /devices/pseudo/pm@0:pm
+	    151261 crw-rw-rw-   1 root     sys      117,  0 ...
+	    $ lsof /devices/pseudo/pm@0:pm
+	    COMMAND ... DEVICE ...   NODE NAME
+	    powerd       117,1 ... 151261 /devices/pseudo/pm@0:pm (COMMON)
+	    Xsun    ...  117,0 ... 151261 /devices/pseudo/pm@0:pm
+
+	Note that the DEVICE value for the file with (COMMON) in
+	its name field has a different minor device number (1) from
+	what ls reports (0), while the DEVICE value for the file
+	without (COMMON) matches the ls output exactly.  Both match
+	on the major device number, 117.  The minor device number
+	mis-match is a result of the way the Solaris kernel handles
+	special file system common vnodes, and it's the reason lsof
+	puts (COMMON) after the name to signal that a mis-match is
+	possible.
+
+17.14	Why don't lsof and Solaris pfiles reports always match?
+
+	/usr/proc/bin/pfiles for Solaris 2.6, 7, 8, and 9 also
+	reports information on open files for processes.  Sometimes
+	the information it reports differs from what lsof reports.
+
+	There are several reasons why this might be true.  First,
+	because pfiles is a Sun product, based on Sun kernel
+	features, its developers have a better chance of knowing
+	exactly how open file information is organized.  I sometimes
+	have to guess at how kernel file structure linkages are
+	constructed by gleaning hints from header files.
+
+	Second, lsof is aimed at providing information, specifically
+	device and node numbers, that can be used to identify named
+	file system objects -- i.e., path names.  Thus, lsof tries
+	to make sure its device and node numbers match those reported
+	by stat(2).  Pfiles doesn't always report numbers that
+	match stat(2) -- e.g., for files using clone and pseudo
+	devices via common vnodes like the nlist() /dev/ksyms usage.
+
+	Here's the Solaris 7 COMMON VCHR example again with additional
+	pfiles output:
+
+	    $ ls -li /devices/pseudo/pm@0:pm
+	    151261 crw-rw-rw-   1 root     sys      117,  0 ...
+	    $ lsof /devices/pseudo/pm@0:pm
+	    vic1: 10 = lsof /dev/pm
+	    COMMAND ... DEVICE ...   NODE NAME
+	    powerd  ...  117,1 ... 151261 /devices/pseudo/pm@0:pm (COMMON)
+	    Xsun    ...  117,0 ... 151261 /devices/pseudo/pm@0:pm
+	    $ pfiles ...
+	    0: S_IFCHR ... dev:32,24 ino:61945 ... rdev:117,1
+	    ...
+	    14: S_IFCHR ... dev:32,24 ino:151261 ... rdev:117,0
+
+	Note that the NODE number, reported by lsof, matches what
+	ls(1) and stat(2) report, while the ino value pfiles reports
+	doesn't.   Lsof also indicates with the (COMMON) notation
+	that the DEVICE number is a pseudo one, derived from the
+	character device's value.  The lsof DEVICE value matches
+	the pfiles rdev value, correct behavior for a character
+	device, but pfiles gives no sign that it's not possible to
+	find that character device number in /devices with ls(1)
+	or stat(2).
+
+17.15	Why does lsof say, "kvm_open(namelist=default, core=default):
+	Permission denied?"
+
+	Lsof needs permission to read from the /dev/kmem and /dev/mem
+	memory devices.  Access to them is opened via a call to
+	the kvm_open() library function and it reports the indicated
+	message.
+
+	You must give lsof permission to read the memory devices.
+	The super user can almost always do that, but other lsof
+	users can do it if some group -- e.g., sys -- has permission
+	to read the memory devices, and the lsof binary is installed
+	with the group's ownership and with the setgid permission
+	bit enabled.
+
+17.16	Why is lsof slow on my busy Solaris UFS file system?
+
+	Lsof may be slow on a busy Solaris UFS file system when
+	UFS logging has been enabled with the "logging" mount
+	option.  That option can significantly increase disk
+	operations under certain conditions -- e.g., when a lot of
+	files are accessed quickly.
+
+	When only the "logging" option is specified to mount, all
+	file accesses (atime updates) are logged to the UFS logging
+	queue.  Each atime update requires two writes to the disk
+	to complete it.
+
+	If you want to do UFS logging -- and there are reliability
+	advantages to it -- consider using the "logging,noatime"
+	mount options instead.  That will shift atime updates from
+	the logging queue to fewer and independent asynchronous
+	operations, consequently making the UFS logging queue a
+	smaller bottleneck.
+
+	Consult mount_ufs(1M) for more information on the logging
+	and noatime options.
+
+	(My thanks to Casper Dik for this tip on improving the
+	performance of UFS logging.)
+
+17.17	Why is lsof so slow on my Solaris 8 or 9 system?
+
+	Solaris 8 has a post-release feature upgrade modifying
+	kernel name cache (DNLC) handling that can slow lsof
+	throughput dramatically.  The feature, sometimes called
+	negative DNLC caching, is standard in Solaris 9.
+
+	As best I can tell, when you install the Solaris 8 MU1
+	package, you get negative DNLC caching.  If this pipe
+	produces any output, your system has negative DNLC caching.
+
+	    $ nm /dev/ksyms | grep negative_cache_vnode
+
+	The reason negative DNLC caching perturbs lsof is that a
+	single vnode address (found in the negative_cache_vnode
+	kernel variable) is used to mark entries in the DNLC that
+	are not (the negative part) found on disk.
+
+	Since a single vnode address (the DNLC key lsof uses) can
+	represent many (I've seen upwards of 30,000.) DNLC entries,
+	their presence overloads lsof's internal DNLC hashing
+	function.  An overloaded hash function is a slow hash
+	function, and lsof's slows to a crawl when it encounters
+	thousands of keys that produce the same value when the lsof
+	DNLC hash function is applied to them.
+
+	The solution is simple -- ignore negative DNLC cache keys.
+	They don't represent path name components lsof can use.
+	Lsof revisions 4.50 and above have an addition that ignores
+	them and the performance of those lsof revisions improves
+	significantly when presented with negative DNLC cache keys.
+
+	If you don't have an lsof revision at 4.51 or later, there's
+	a work-around.  Use lsof's ``-C'' option.  It disables
+	lsof's DNLC caching.  Of course, that also inhibits the
+	reporting of any path name components from the kernel DNLC.
+	When ``-c'' is used, lsof will continue to report file
+	system and character device paths.
+
+17.18	Solaris and VxFS
+
+17.18.1	Why doesn't lsof support VxFS 3.4 on Solaris 2.6, and above?
+
+	Lsof will not support VxFS version 3.4 on Solaris 2.6 and above
+	unless some files from VxFS Update 2 have been installed.  VxFS
+	3.4 FCS and VxFS 3.4 update 1 lack the header files lsof
+	normally uses to obtain information from the VxFS 3.4 kernel
+	node structure, vx_inode.  VxFS 3.4 Update 2 provides a method
+	whereby lsof can obtain the necessary vx_inode information from
+	the vxfsu_get_ioffsets() function in Veritas utility
+	libraries.
+
+	The utility libraries (32 bit and 64 bit versions) may be
+	found in /opt/VRTSvxfs/lib.  An ancillary header file may
+	be found in /opt/VRTSvxfs/include/sys/fs/vx_libutil.h.
+	Documentation of the vxfsu_get_ioffsets(3) function may be
+	found in /opt/VRTS/man/man3/vxfsu_get_ioffsets.3.
+
+	Those files of VxFS 3.4 Update 2 may be downloaded from:
+
+	    ftp://ftp.veritas.com/pub/support/vxfs_34.i64243.tar
+
+	The vxfs_34.i64243.tar archive will unpack into an i64243
+	directory containing these files:
+
+	    $ ls i64243
+	    README
+	    libvxfsutil.sol26.sums
+	    libvxfsutil.sol26.tar.Z
+	    libvxfsutil.sol27.sums
+	    libvxfsutil.sol27.tar.Z
+	    libvxfsutil.sol28.sums
+	    libvxfsutil.sol28.tar.Z
+
+	Read README.  Select the *.tar.Z file appropriate for your
+	Solaris version.  Its contents will unpack into /opt/VRTS
+	and /opt/VRTSvxfs, so you will need sufficient permission
+	-- e.g., do it as root -- to unpack the uncompressed archive.
+	Once you've done that, it's a good idea to compare the
+	checksums of the archive you unpacked with the ones recorded
+	in the appropriate *.sums file.  Use `sum -r` to verify
+	the checksums.
+
+	For example, if you want the Solaris 8 version, uncompress
+	and unpack libvxfsutil.sol28.tar.Z -- e.g.,
+	
+	    $ su
+	    ...
+	    # cd i6423
+	    # zcat libvxfsutil.sol28.tar.Z | tar xf -
+
+	That should create these new files and subdirectories with
+	the indicated checksums:
+
+	    File or subdirectory			sum -r
+
+	    /opt/VRTSvxfs/include/vxfsutil.h		03938
+	    /opt/VRTSvxfs/lib/libvxfsutil.a		51794
+	    /opt/VRTSvxfs/lib/sparcv9/
+	    /opt/VRTSvxfs/lib/sparcv9/libvxfsutil.a	07420
+	    /opt/VRTS/man/man3/
+	    /opt/VRTS/man/man3/vxfsu_get_ioffsets.3	62480
+
+	Once these files are in place, run lsof's Configure script
+	for the solaris or solariscc abbreviation.  Configure will
+	locate the appropriate VxFS 3.4 Update 2 files and set up
+	for the making of an lsof that will properly display open
+	VxFS 3.4 file information.
+
+17.18.2	Why does lsof report "vx_inode: vxfsu_get_ioffsets error"
+	for open Solaris 2.6 and above VxFS 3.4 and above files?
+
+	Even when lsof supports VxFS 3.4 and above on Solaris 2.6 and
+	above, it may report "vx_inode: vxfsu_get_ioffsets error" in
+	the NAME column for all VxFS files.
+
+	The usual cause is that lsof doesn't have permission to
+	read the file at the end of the /dev/vxportal symbolic
+	link.  If, for example, lsof has been installed setgid(sys),
+	then the /dev/vxportal symbolic link destination should be
+	owned by the sys group and readable by it.
+
+	Update 2 for VxFS 3.4 sets the modes of the /dev/vxportal
+	symbolic link destination to 0640 and the group ownership
+	to sys.  But I have had a report that the modes are wrong
+	in a VxFS 4.0 installation.
+
+	Another cause may be that the system has more than one version
+	of VxFS installed (Only one can be active.), and lsof's
+	Configure script did not choose the header files and libraries
+	for the active VxFS version.  Configure opts for VxFS 4.0 and
+	above header files and libraries (in /opt/VRTS) in preference
+	to those for VxFS below 4.0 (in /opt/VRTSvxfs).
+
+	Look for the directories /opt/VRTS and /opt/VRTSvxfs.  If you
+	have /opt/VRTS, make sure its header and library symbolic links
+	point to those of the active VxFS version.
+	
+	If you have both directories, look at the CFLAGS that Configure
+	constructed for making lsof and see which directory path
+	follows a -I option.  If that doesn't match the directory path
+	of the active VxFS version, try pointing Configure at the
+	correct directory with the SOLARIS_VXFSINCL environment
+	variable -- e.g.,
+
+	    $ SOLARIS_VXFSINCL=/opt/.../include ./Configure -n solaris
+
+17.18.3	Why does Solaris Configure claim there is no VxFS library?
+
+	The lsof Configure script, when configuring for Solaris, may
+	report:
+
+	    FATAL: no VxFS .../libvxfsutil.a
+	
+	That fatal error message indicates lsof has found the VxFS
+	utility library's header files, but can't find the library
+	itself in the expected location adjacent to the header files.
+
+	One possible cause is an incorrect symbolic link from
+	/opt/VRTS/lib/sparcv9/libvxfsutil.a to the library's real
+	location.  (Some VxFS distributions declared the link
+	incorrectly.)  Use `ls -lL` on that path to see if it exists.
+	If it doesn't exist, the link may be missing an additional
+	leading "../" component.
+
+	If the problem is a missing "../" from the library's link, you
+	can correct the link or check with Veritas/Symantec for the
+	patch that corrects it.
+
+	If the problem is not a missing "../", and you know the
+	libvxfsutil.a location, you can define its path in the
+	SOLARIS_VXFSLIB environment variable before running the lsof
+	Configure script.  (See 00XCONFIG for information about using
+	the SOLARIS_VXFSLIB environment variable.)
+
+	If you have no libvxfsutil.a, you must obtain it from
+	Veritas/Symantec or find it in your VxFS installation package.
+
+17.18.4 Why doesn't Solaris lsof report VxFS path name components?
+
+	Solaris lsof will report path name components for VxFS versions
+	that use the common Solaris Dynamic Name Lookup Cache (DNLC) or
+	on some file systems of VxFS versions that support the VxFS
+	Reverse Name Lookup (RNL) facility.
+
+	VxFS versions 3.3 (approximately) and below use the common
+	Solaris DNLC.  (I haven't been able to determine exactly when
+	VxFS stopped using the DNLC.)  For versions above that boundary,
+	but below 4.0, lsof can't report path name components.
+
+	At VxFS 4.0 and above, lsof can be compiled to use the VxFS RNL
+	facility for reporting path names.  If "-DHASVXFSRNL" appears
+	in the compiler flags section of lsof "-v" option output, then
+	the lsof Configure script detected the VxFS RNL facility and
+	lsof has been compiled to use it.
+
+	Lsof's use of the RNL facility can fail when the VxFS file
+	system disk layout version is below 6.  In that case, lsof can
+	report no path name components.  For more information, see the
+	vxfs_inotopath(3) manual page.  any of the following commands
+	will show the disk layout version for a VxFS file system, when
+	supplied the block device or mount point on which the file
+	system is mounted.
+
+	    fstyp -v <block_device>
+	 or
+	    mkfs -m <block_device>
+	 or
+	    vxupgrade <mount_point>
+
+	You must have permission to read the block device -- e.g., be
+	the root user.
+
+	You may also be able to upgrade an older disk layout to one
+	that will work with the RNL.  See the vxupgrade(1M) man page
+	for more information on that.
+
+	When lsof can't report VxFS path name components, it reports
+	the file system mount point and the path name of device on
+	which it is mounted.  The device path name is enclosed in
+	parentheses.
+
+17.18.5	Why does Solaris 10 lsof report scrambled VxFS paths?
+
+	Solaris 10 lsof may report a bogus, scrambled path for an open
+	VxFS file, when lsof obtains the path from a vnode's cached
+	path.  Veritas/Symantec reports that their Solaris 10
+	implementation has bugs in the way it handles the Solaris 10
+	vnode cached path and those bugs will be fixed in an upcoming
+	patch some time after August 15, 2005.
+
+	When Solaris 10 lsof reports a path for an open VxFs file
+	obtained via the VxFS Reverse Name Lookup facility, the path
+	will be correct.
+
+	Also see the answers to the questions "Why does Solaris 10 lsof
+	sometimes report the wrong path name?" and "Why doesn't Solaris
+	lsof report VxFS path name components?"
+
+17.19	Large file problems
+
+17.19.1	Why does lsof complain it can't stat(2) a Solaris 2.5.1
+	large file?
+
+	When given an argument that is the path to a Solaris 2.5.1
+	file, enable for large file operations with the O_LARGEFILE
+	open(2) option, lsof complains that it can't stat(2) the
+	file.  That's because lsof isn't using a stat(2) call and
+	associated structure enabled for large files.
+
+	This error has been fixed, starting at lsof revision 4.58
+	for Solaris 2.6 and above.  That fix won't work on Solaris
+	2.5.1 and I no longer have access to a Solaris 2.5.1 test
+	system to develop a separate fix.
+
+	The work-around is to avoid specifying a O_LARGEFILE path
+	as an argument to lsof on Solaris 2.5.1.  Instead use a
+	combination of lsof and grep to achieve the same results,
+	albeit more clumsily.
+
+17.20   Why does lsof get a segmentation fault on 64 bit Solaris
+	8 using NIS+?
+
+	I have received a report from Gary Craig that lsof produces
+	a segmentation fault on his 64 bit Solaris 8 system using
+	NIS+.  Via an independent test program we have exonerated
+	lsof and tracked the fault to the NIS+ __nis_server_name()
+	function in the C name server library, -lnsl.
+
+	Lsof causes the __nis_server_name() NIS+ function to be
+	called by calling getservent() to read entries of the port
+	number to service name map.
+
+	The only Sun bug ID that appears to describe the problem
+	is 4304244, although its text is unclear enough to leave
+	room for doubt.
+
+	Until Sun eliminates the __nis_server_name() segmentation
+	fault cause, a work-around for lsof is to use its "-P"
+	option, causing lsof to avoid port to service name lookups.
+
+17.21	Will lsof crash the Solaris kernel?
+
+	I've received and investigated one report that it has when
+	the Sun hardware (a QME interface) was faulty.  Today (May
+	23, 2002) I've learned that Sun has reports of kernel
+	crashes caused by adb, lsof, and mdb.
+
+	The Sun investigation pinpointed a problem in the /dev/kmem
+	kernel driver and there is a Sun bug report, 4344513, about
+	the problem.  There is a fix in Solaris 9, and patches for
+	Solaris 7 and 8 (SPARC and x86).
+
+	To see if your Solaris system is fixed, look for a
+	/devices/pseudo/*allkmem node.
+
+	Extensive address filtering was added to lsof revision 4.50
+	to forestall what I then (July 2001) believed to be only
+	the possibility that lsof might crash Solaris.  However,
+	the filtering isn't perfect, since a filtered address might
+	become invalid after lsof has filtered it but before lsof
+	has delivered it to /dev/kmem.  That filtering work is
+	described in .../dialects/sun/solaris_kaddr_filters, also
+	available at:
+
+	ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/solaris_kaddr_filters
+
+	The best and safest work-around is to upgrade to Solaris
+	9 or install an appropriate patch or its equivalent from
+	this list:
+
+	    Solaris	SPARC		x86
+	    Version	Patch		Patch
+	    =======	=====		=====
+	       7	106541-20	106542-20
+	       8	108528-14	108529-14
+
+17.22   Why does lsof on Solaris 7, 8, or 9 report a kvm_open()
+	failure?
+
+	When lsof is started on some Solaris 7, 8, and 9 systems
+	it may report:
+
+	    lsof: kvm_open(namelist=default, corefile=default): \
+		  No such file or directory
+
+	Lsof revisions 4.65 and later will first report:
+
+	    lsof: cannot stat /dev/allkmem
+
+	The second message, not delivered in lsof revisions below
+	4.65, explains the cause of the kvm_open() failure; it
+	can't find /dev/allkmem.
+
+	/dev/allkmem is a device added to Solaris 7 and 8 in patches
+	and in the Solaris 9 FCS.  See the preceding "Will lsof
+	crash the Solaris kernel?" section for more information on
+	/dev/allkmem and the patches.
+
+	The kvm_open(3KVM) function in the KVM library of patched
+	Solaris 7 and 8 systems and in Solaris 9 expects to find
+	/dev/allkmem and exits on error when it does not.
+
+	If you have installed the patch that updated your KVM
+	library to a version that expects /dev/allkmem to be present
+	and it is not, you may need to reconfigure your system's
+	devices with devfsadm(1M) or enter "boot -r" to the OpenBoot
+	monitor's prompt (usually "ok").
+
+17.23	Solaris and SAM-FS
+
+17.23.1	Why does Solaris lsof report "(limited SAM-FS info)"?
+
+	Lsof 4.68 and above report "(limited SAM-FS info)" on
+	Solaris in the NAME column after the path or file system
+	name for all files it finds on SAM-FS file systems.
+
+	That's because no more information is known about the
+	composition of the nodes that follow SAM-FS vnodes.  If
+	you can provide that information, please contact me via
+	e-mail at <abe@purdue.edu>.  Make sure "lsof" appears in the
+	"Subject:" line so my e-mail filter won't classify your letter
+	as Spam.
+
+17.23.2	Why can't lsof locate named SAM-GS files?
+
+	Solaris lsof 4.68 and above can't locate files on SAM-FS
+	file systems when the files are named as lsof arguments
+	because lsof doesn't know how to locate open SAM-FS file
+	device and node number information.  (See also 'Why does
+	Solaris lsof report "(limited SAM-FS info)?')
+
+17.24	Lsof and Solaris 10 zones
+
+17.24.1	How can I make lsof list the Solaris zone?
+
+	Use the lsof "-z [z]" option.
+
+17.24.2	Why doesn't lsof work in a Solaris 10 zone?
+
+	When run from within a Solaris 10 zone, lsof will usually
+	report:
+
+	    lsof: can't stat(/devices): No such file or directory
+
+	That's because a Solaris zone usually has no /devices
+	subdirectory, a restriction of the zone implementation intended
+	to limit the ability of zone processes to control global system
+	resources, including physical devices.
+
+	While a zone may have a /dev subdirectory, that subdirectory
+	usually lacks the /dev/allkmem, /dev/mem and /dev/kmem devices
+	lsof and the KVM library it uses require.
+
+	The work-around is to run lsof in the global zone.  When it is
+	run in a global zone lsof will be able to report on processes
+	running in any zone, including the global zone.
+
+17.24.3 Why does lsof complain it can't stat() Solaris 10 zone file
+	systems?
+
+	When run from the global zone on Solaris 10 lsof may complain:
+
+	    lsof: WARNING: can't stat() 15 zone file systems;
+			   using dev= options
+
+	The warning message means lsof found the reported number of
+	file system entries in the mount table for which it didn't have
+	permission to get stat(2) results, but which had "zone=" and
+	"dev=" mount table options.
+
+	That is a normal restriction of Solaris 10 zones.  Since the
+	lsof warning message indicates it was able to find "dev="
+	options for the file systems, lsof will probably work
+	correctly.
+
+	One work-around is to relax the restrictions on zone mount
+	points, so that lsof can stat() them.  While that may be
+	possible by changing directory modes or group ownerships, it is
+	probably not a good idea, because it weakens the restrictions
+	zones are intended to provide.
+
+	Another work-around is to suppress the warning message with
+	lsof's "-w" option.  The down side of that is that it causes
+	the suppression of all warning messages, leading to the
+	possibility that some non-stat() warning messages will be
+	suppressed.
+
+17.25	Solaris 10 problems
+
+17.25.1 Why does Solaris 10 lsof sometimes report the wrong path name?
+
+	When a path name component is renamed -- e.g., with mv(1) --
+	Solaris 10 lsof may report the old component for an open file
+	that used the component in its path before the rename.  That's
+	because Solaris 10 lsof reports the path name cached in the
+	open file's vnode and the Solaris 10 kernel doesn't update the
+	open vnode's cached path name when a component of it is changed.
+
+	When an open file is deleted -- e.g., with rm(1) -- the path
+	name by which it was opened remains cached in the vnode.  Lsof
+	can be instructed to display that path name with the -X option.
+	The path name might be incorrect because of the rename problem
+	described above.  See the answer to the 'What does "(deleted)"
+	mean in the NAME column of a Solaris 10 open file?' question
+	for more information.
+
+	Lsof is sometimes able to detect that cached path name is
+	incorrect.  In that case lsof may report only the mounted-on
+	directory and device of the file system or it may report that
+	the path name is of questionable accuracy by appending a
+	trailing "(?)" to it in the NAME column.
+
+	See the answer to the "Why does Solaris 10 lsof sometimes
+	report only the mounted-on directory and device?" and 'What
+	does "(?)" mean in the NAME column of a Solaris 10 open file?'
+	questions for more information.
+
+17.25.2 Why does Solaris 10 lsof sometimes report only the mounted-on
+	directory and device?
+
+	For some regular open files lsof may report only the mounted-on
+	directory and device of the file system on which the file
+	resides.  That's because lsof was able to determine that the
+	path name cached in the open file's vnode is incorrect.
+
+	Lsof detects the cached path name is incorrect by applying
+	stat(2) to it, provided that no error was detected when stat(2)
+	was applied to the file system mounted-on directory during lsof
+	setup.  If a mounted-on directory stat(2) error was detected
+	during setup, lsof does no cached path name analysis and simply
+	reports it.
+
+	When the application of stat(2) to the cached path name returns
+	a no-entry reply (the ENOENT error number), lsof concludes the
+	path no longer exists (i.e., has been unlinked) and reports the
+	mounted-on directory and device of the file system.  That
+	behavior can be modified with the -X option in lsof revisions
+	4.77 and above.  See the answer to the 'What does "(deleted)"
+	mean in the NAME column of a Solaris 10 open file?' for more
+	information.
+
+	When the application of stat(2) to the cached path name returns
+	a permission error reply (the EACCES or EPERM error numbers),
+	lsof reports the cached path name and adds a trailing "(?)" to
+	indicate the reported path name is of questionable accuracy.
+	See the answer to the question 'What does "(?)" mean in the
+	NAME column of a Solaris 10 open file?' for more information.
+
+	If the application of stat(2) to the cached path name yields
+	any other error reply, lsof reports the mounted-on directory
+	and device of the file system.
+
+	When the application of stat(2) to the cached path name
+	succeeds, lsof compares the reported device and node numbers to
+	what it has obtained for the open file from kernel structures.
+	If they match, lsof reports the cached path name.  If they
+	don't match, lsof instead reports the mounted-on directory and
+	device of the file system.
+
+	A work-around that allows lsof to apply stat(2) successfully to
+	cached path names is to give lsof sufficient permission to do
+	it -- i.e., run lsof as the root user.
+
+17.25.3	What does "(deleted)" mean in the NAME column of a Solaris 10
+	open file?
+
+	When the -X option is specified to Solaris 10 lsof, it will
+	report in its NAME column the path name cached for a deleted
+	file in its vnode.  The path name will be followed by
+	"(deleted)".
+
+	Note that the path name cached in a file's vnode is the path
+	name by which the file was opened.  It is not updated by the
+	Solaris kernel when any path name component is changed.  Hence,
+	it may not represent the final path name the open file had.
+
+	See the answer to the "Why does Solaris 10 lsof sometimes
+	report the wrong path name?" question for more information on
+	how changing a path name component affects the correctness of a
+	what lsof reports.
+
+17.25.4 What does "(?)" mean in the NAME column of a Solaris 10 open
+	file?
+
+	When lsof encounters a path name cached in the open file's
+	vnode that stat(2) reports lsof lacks permission to access,
+	lsof adds "(?)" to the path name reported in the NAME column to
+	indicate the path name is of questionable accuracy.
+
+	See the answers to the "Why does Solaris 10 lsof sometimes
+	report the wrong path name?" and "Why does Solaris 10 lsof
+	sometimes report only the mounted-on directory and device?"
+	questions for more information on why lsof may report a path
+	name of questionable accuracy.
+
+	A work-around that allows lsof to apply stat(2) successfully to
+	cached path names is to give lsof sufficient permission to do
+	it -- i.e., run lsof as the root user.
+
+17.26	Solaris contract file problems
+
+17.26.1	Why doesn't lsof report size, link count and node number for
+	Solaris 10 contract files?
+
+	Lsof doesn't report size, link count or node number for Solaris
+	10 contract files because I don't know how to obtain them from
+	contract file kernel structures.
+
+17.26.2	Why can't lsof locate a Solaris 10 contract file by path name?
+
+	Because lsof can't find the node number of Solaris contract
+	files, it can't match the device and node numbers it gets from
+	applying stat(2) to the contract file path name with what it
+	finds in kernel data.
+
+17.27	Solaris 10 and above ZFS probblems
+
+17.27.1	Why does Configure warn that ZFS support is not enabled?
+
+	To provide ZFS support it is necessary that lsof have access to
+	the definitions of ZFS structures used by the kernel.  Those
+	definitions are made available to lsof when it runs by the
+	libctl library.
+
+	If lsof's Configure script finds that ZFS is indicated by the
+	presence of the <sys/fs/zfs.h> header file, but the libctl
+	library is not indicated via the <libctl.h> header file, the
+	script concludes that ZFS support is not possible and issues
+	the following warning:
+
+	  WARNING: ZFS support not enabled; libctf.h missing.
+
+	Install libctf support to remedy this problem.
+
+
+17.28	Problems with Solaris 9 and above
+
+17.28.1	Why does the compiler complain about lgrp_root on Solaris 9
+	and above?
+
+	When compiling lsof 4.84 on later Solaris 9 and 10 systems, the
+	compiler may report the following error:
+
+	  /usr/include/sys/lgrp.h", line ...: identifier redeclared: lgrp_root
+
+	This error results from a conflict between usage of lgrp_root
+	in both <sys/lgrp.h> and <sys/lgrp_user.h> when _KMEMUSER or
+	_KERNEL is #define'd before <sys/lgrp.h> is #include'd.  This
+	problem is noted in Sunsolve bug ID 5064229.
+
+	The work-around is to use lsof revision 4.85 sources.
+
+
+18.0	Lsof Features
+
+18.1	Why doesn't lsof doesn't report on /proc entries on my
+	system?
+
+	/proc file system support is generally available only for
+	BSD, SYSV R4 dialects, and Tru64 UNIX (Digital UNIX, DEC
+	OSF/1).  It's also available for Linux, and Pyramid DC/OSx
+	and Reliant UNIX.
+
+	Even on some SYSV R4 dialects I encountered many problems
+	while trying to incorporate /proc file system support.
+	The chief problem is that some vendors don't distribute
+	the header file that describes the /proc file system node
+	-- usually called prdata.h.
+
+18.2	How do I disable the device cache file feature or alter
+	it's behavior?
+
+	To disable the device cache file feature for a dialect,
+	remove the HASDCACHE definition from the machine.h file of
+	the dialect's machine.h header file.  You can also use
+	HASDCACHE to change the default prefix (``.lsof'') of the
+	device cache file.
+
+	Be sure you consider disabling the device cache file feature
+	carefully.  Having a device cache file significantly reduces
+	lsof startup overhead by eliminating a full scan of /dev
+	(or /devices) once the device cache file has been created.
+	That full scan also overloads the kernel's name cache with
+	the names of the /dev (or /devices) nodes, reducing the
+	opportunity for lsof to find path name components of open
+	files.
+
+	If you're worried about the presence of mode 0600 device
+	cache files in the home directories of the real user IDs
+	that execute lsof, consider these checks that lsof makes
+	on the file before using it:
+
+	    1.  To read the device cache file, lsof must gain
+		permission from access(2).
+
+	    2.  The device cache file's modes must be 0600 (0644
+		if lsof is reading a system-wide device cache file)
+		and its size non-zero.
+
+	    3.  There must be a correctly formatted section count
+		line at the beginning of the file.
+
+	    4.  Each section must have a header line with a count
+	        that properly numbers the lines in the section.
+		Legal sections are device, clone, pseudo-device,
+		and CRC.
+
+	    5.  The lines of a section must have the proper format.
+
+	    6.  All lines are included in a 16 bit CRC, and it is
+		recorded in a non-checksummed section line at the
+		end of the file.
+
+	    7.  The checksum computed when the file is read must
+		match the checksum recorded when the file was
+		written.
+
+	    8.  The checksum section line must be followed by
+		end-of-information.
+
+	    9.  Lsof must be able to get matching results from
+		stat(2) on a randomly chosen entry of the device
+		section.
+
+	For more information on the device cache file, read the
+	00DCACHE file of the lsof distribution.
+
+18.2.1	What's the risk with a perverted device cache file?
+
+	Even with the checks that lsof makes on the device cache
+	file, it's conceivable that an intruder could modify it so
+	it would pass lsof's tests.
+
+	The only serious consequence I know of this change is the
+	removal of a file whose major device number identifies a
+	socket from some user ID's device cache file.  When such
+	a device has been removed from the device cache file, and
+	when lsof doesn't detect the removal, lsof may not be able
+	to identify socket files when executed by the affected user
+	ID.  Only certain dialects are at risk to this attack --
+	e.g., SCO OpenServer and Solaris 2.x, 7, 8, and 9.
+
+	If you're tracking a network intruder with lsof, that could
+	be important to you.  If you suspect that someone has
+	corrupted the device cache file you're using, I recommend
+	you use lsof's -Di option to tell it to ignore it and use
+	the contents of /dev (or /devices) instead; or remove the
+	device cache file (usually .lsof_hostname, where hostname
+	is the first component of the host's name returned by
+	gethostname(2)) from the user ID's home directory and let
+	lsof create a new one for you.
+
+18.2.2	How do I put the full host name in a personal device cache file
+	path?
+
+	Lsof constructs the personal device cache file path name
+	from a format specified in the HASPERSDC #define in the
+	dialect's machine.h header file.  As distributed HASPERSDC
+	declares the path to be ``.lsof_'' plus the first component
+	of the host name with the format ``.lsof_%L''.
+
+	If you want to change the way lsof constructs the personal
+	device cache file path name, you can change the HASPERSDC
+	#define and recompile lsof.  If, for example, you #define
+	HASPERSDC to be ``.lsof_%l'' (note the lower case `l'),
+	Configure and remake lsof, then the personal device cache
+	file path will be ``.lsof_'' plus the host name returned
+	by gethostname(2).
+
+	See the 00DCACHE file of the lsof distribution for more
+	information on the formation of the personal device cache
+	file path and the use of the HASPERSDC #define.
+
+18.2.3	How do I put the personal device cache file in /tmp?
+
+	Change the HASPERSDC definition in your dialect's machine.h
+	header file.
+	
+	When you redefine HASPERSDC, make sure you put at least
+	one user identification conversion in it to keep separate
+	the device cache files for each user of lsof.  Also give
+	some thought to including the ``%0'' conversion to define
+	an alternate path for setuid-root and root processes.
+
+	Here's a definition that puts a personal device cache file
+	in /tmp with the name ``.lsof_login_hostname_pers''.
+
+	    #define HASPERSDC "/tmp/.lsof_%u_%l_pers"
+
+	Thus the /tmp personal device cache file path for login
+	"abe" on host "lsof.itap.purdue.edu" would be:
+
+	    /tmp/.lsof_abe_lsof.itap.purdue.edu_pers
+
+	You can add the User ID (UID) with the "%U" conversion and
+	the first host name component with the ``%L'' conversion.
+
+	CAUTION: be careful using absolute paths like /tmp lest
+	lsof processes that are setuid-root or whose real UID is
+	root be used to exploit some security weakness via /tmp.
+	Elect instead to add an alternate path for those processes
+	with the ``%0'' conversion.  Here's an extension of the
+	previous HASPERSDC format for /tmp that declares an alternate
+	path:
+
+	    #define HASPERSDC "/tmp/.lsof_%u_%l_pers%0%h/.lsof_%L"
+
+	When the lsof process is setuid-root or its real UID is
+	root, presuming root's home directory is `/' and the host's
+	name is ``lsof.itap.purdue.edu'', the extended format yields:
+
+	    /.lsof_vic
+
+18.3	Why doesn't lsof know about AFS files on my favorite dialect?
+
+	Lsof currently supports AFS for these dialects:
+
+	    AIX 4.1.4 (AFS 3.4a)
+	    Linux 1.2.13 (AFS 3.3)
+	    NEXTSTEP 3.2 (AFS 3.3)
+	    Solaris 2.[56] (AFS 3.4a)
+
+	It may recognize AFS files on other versions of these
+	dialects, but I have no way to test that.  Lsof may report
+	correct information for AFS files on other dialects, but
+	I can't test that either.
+
+	AFS support must be custom crafted for each UNIX dialect
+	and then tested.  If lsof supports your favorite dialect,
+	but doesn't recognize its AFS files, probably I don't have
+	access to a test system.  If you want AFS support badly
+	for your dialect, consider helping me do the development
+	and testing.
+
+18.3.1	Why doesn't lsof report node numbers for all AFS volume files,
+	or how do I reveal dynamic module addresses to lsof?
+
+	When AFS is implemented via dynamic kernel modules -- e.g.,
+	in NEXTSTEP -- lsof can't obtain the addresses of AFS
+	variables in the kernel that it uses to identify AFS vnodes.
+	It can guess that a vnode is assigned to an AFS file and
+	it can obtain other information about AFS files, but it
+	has trouble computing AFS volume node numbers.
+
+	To determine node numbers for AFS volumes other than the
+	root volume, /afs, lsof needs access to a hashed volume
+	structure pointer table.  When it can't find the address
+	of that table, because AFS support is implemented via
+	dynamic kernel modules, lsof will return blanks in the
+	INODE column for AFS volume files.  Lsof can identify the
+	root volume's node number (0), and can compute the node
+	numbers for all other AFS files.
+
+	If you have a name list file that contains the addresses
+	of the AFS dynamic modules -- e.g., you saved module symbols
+	when you created a loadable module kernel with modload(8)
+	by specifying -sym -- lsof may be able to find the kernel
+	addresses it needs in that file.
+
+	Lsof looks up AFS dynamic kernel addresses for these dialects
+	at these default paths:
+
+	    NEXTSTEP 3.2	/usr/vice/etc/afs_loadable
+
+	A different path to a name list file with AFS dynamic kernel
+	addresses may be specified with the -A option, when the -A
+	option description appears in lsof's -h or -? (help) output.
+
+	If any addresses appear in the -A name list file that also
+	appear in the regular kernel name list file -- e.g., /vmunix
+	-- they must match, or lsof will silently ignore the -A
+	addresses on the presumption that they are out of date.
diff --git a/00LSOF-L b/00LSOF-L
new file mode 100644
index 0000000..7a58df6
--- /dev/null
+++ b/00LSOF-L
@@ -0,0 +1,100 @@
+
+		    The Lsof Mailing List, lsof-l
+
+Information on lsof is available via a GNU Mailman mailing list, named
+lsof-l.  The server is located on the host rcac.purdue.edu.
+
+
+Subscribing
+===========
+
+You may subscribe to the lsof-l mailing list by sending e-mail to:
+
+  lsof-l-subscribe@rcac.purdue.edu
+
+The body of your e-mail may be empty.  You will receive a confirmation
+reply, explaining one further step you must take to complete your
+subscription.
+
+The list manager uses the e-mail address and real name in the "From:"
+line of your request to set those values in your subscription.  If you
+want different values in your subscription, consult the Mailman help
+information to learn how to specify them on your subscription request.
+(See the next "Get Help" section on how to obtain Mailman help
+information.)
+
+
+Get Help
+========
+
+More information about the rcac.purdue.edu GNU Mailman server is
+available by sending e-mail to lsof-l-request@rcac.purdue.edu with
+"help" in the subject line.  The body of your e-mail may be empty.
+
+The other information will be delivered by return e-mail.
+
+You can also obtain information on the Mailman e-mail commands in
+section 3.2 of the GNU Mailman documentation at:
+
+  http://www.gnu.org/software/mailman/mailman-member/mailman-member.html
+
+
+The Web Interface
+=================
+
+There is a web interface at:
+
+  https://lists.rcac.purdue.edu/listinfo/lsof-l
+
+You can use it to manage your lsof-l list entry.
+
+
+Posting and Moderation
+======================
+
+Once you have subscribed to lsof-l (and have an e-mail confirmation
+that your subscription was accepted), you may post messages to the list
+by sending e-mail directly to:
+
+  lsof-l@rcac.purdue.edu
+
+I moderate the lsof-l mailing list and try to keep its traffic low,
+mainly limiting it to announcements of new revisions, patches and
+security issues.  Postings don't appear until I've approved them.
+
+
+Send Bug Reports to Me Via E-Mail
+=================================
+
+DON'T SEND BUG REPORTS TO lsof-l.  Send them directly to me via e-mail
+at <abe@purdue.edu>.  Make sure lsof appears in the "Subject:" line and
+make sure you first read the "Bug Reports" section of the 00README file
+of the lsof distribution.
+
+
+Unsubscribing
+=============
+
+You can unsubscribe from lsof-l by sending e-mail to:
+
+  lsof-l-unsubscribe@rcac.purdue.edu
+
+The body of your e-mail may be empty.  You will receive a confirmation
+reply, explaining one further step you must take to complete the
+removal of your subscription.
+
+
+Archive
+=======
+
+There is an archive; use the link:
+
+  https://lists.rcac.purdue.edu/listinfo/lsof-l
+
+The archive link is the first one on the web page.  You will need the
+password you received or set when you subscribed, or later set via
+lsof-l-request or the web interface.
+
+
+Vic Abell <abe@purdue.edu>
+May 8, 2008
diff --git a/00MANIFEST b/00MANIFEST
new file mode 100644
index 0000000..6e2fae8
--- /dev/null
+++ b/00MANIFEST
@@ -0,0 +1,364 @@
+.:
+00.README.FIRST
+00CREDITS
+00DCACHE
+00DIALECTS
+00DIST
+00FAQ
+00LSOF-L
+00MANIFEST
+00PORTING
+00QUICKSTART
+00README
+00TEST
+00XCONFIG
+AFSConfig*
+ChangeLog
+Configure*
+Customize*
+Inventory*
+arg.c
+dialects/
+lib/
+lsof.8
+lsof.h
+lsof.man
+lsof_fields.h
+main.c
+misc.c
+node.c
+print.c
+proc.c
+proto.h
+regex.h
+scripts/
+store.c
+tests/
+usage.c
+util.c
+version
+
+./dialects:
+aix/
+darwin/
+du/
+freebsd/
+hpux/
+linux/
+n+obsd/
+n+os/
+osr/
+sun/
+uw/
+
+./dialects/aix:
+Makefile
+Mksrc*
+aix5/
+ddev.c
+dfile.c
+dlsof.h
+dmnt.c
+dnode.c
+dnode1.c
+dnode2.c
+dproc.c
+dproto.h
+dsock.c
+dstore.c
+machine.h
+
+./dialects/aix/aix5:
+README
+j2/
+
+./dialects/aix/aix5/j2:
+j2_lock.h
+private_j2_snapshot.h
+
+./dialects/darwin:
+get-hdr-loc.sh*
+kmem/
+libproc/
+
+./dialects/darwin/kmem:
+Makefile
+Mksrc*
+ddev.c
+dfile.c
+dlsof.h
+dmnt.c
+dnode.c
+dnode1.c
+dproc.c
+dproto.h
+dsock.c
+dstore.c
+machine.h
+
+./dialects/darwin/libproc:
+Makefile
+Mksrc*
+ddev.c
+dfile.c
+dlsof.h
+dmnt.c
+dproc.c
+dproto.h
+dsock.c
+dstore.c
+machine.h
+
+./dialects/du:
+Makefile
+Mksrc*
+ddev.c
+dfile.c
+dlsof.h
+dmnt.c
+dnode.c
+dproc.c
+dproto.h
+dsock.c
+dstore.c
+machine.h
+
+./dialects/freebsd:
+Makefile
+Makefile.zfs
+Mksrc*
+dlsof.h
+dmnt.c
+dnode.c
+dnode1.c
+dnode2.c
+dproc.c
+dproto.h
+dsock.c
+dstore.c
+dzfs.h
+include/
+machine.h
+
+./dialects/freebsd/include:
+procfs/
+
+./dialects/freebsd/include/procfs:
+pfsnode.h
+
+./dialects/hpux:
+kmem/
+pstat/
+
+./dialects/hpux/kmem:
+Makefile
+Mksrc*
+dfile.c
+dlsof.h
+dmnt.c
+dnode.c
+dnode1.c
+dnode2.c
+dproc.c
+dproto.h
+dsock.c
+dstore.c
+hpux11/
+machine.h
+
+./dialects/hpux/kmem/hpux11:
+ipc_s.h
+kernbits.h
+lla.h
+nfs_clnt.h
+proc.h
+rnode.h
+sth.h
+tcp_s.h
+udp_s.h
+vnode.h
+
+./dialects/hpux/pstat:
+Makefile
+Mksrc*
+dfile.c
+dlsof.h
+dproc.c
+dproto.h
+dsock.c
+dstore.c
+machine.h
+
+./dialects/linux:
+Makefile
+Mksrc*
+dfile.c
+dlsof.h
+dmnt.c
+dnode.c
+dproc.c
+dproto.h
+dsock.c
+dstore.c
+machine.h
+
+./dialects/n+obsd:
+Makefile
+Mksrc*
+dlsof.h
+dmnt.c
+dnode.c
+dnode1.c
+dproc.c
+dproto.h
+dsock.c
+dstore.c
+machine.h
+
+./dialects/n+os:
+Makefile
+Mksrc*
+dlsof.h
+dnode.c
+dnode1.c
+dproc.c
+dproto.h
+dsock.c
+dstore.c
+machine.h
+
+./dialects/osr:
+Makefile
+Mksrc*
+dfile.c
+dlsof.h
+dmnt.c
+dnode.c
+dproc.c
+dproto.h
+dsock.c
+dstore.c
+include/
+machine.h
+
+./dialects/osr/include:
+netdb.h
+sys/
+
+./dialects/osr/include/sys:
+cdefs.h
+
+./dialects/sun:
+Makefile
+Mksrc*
+ddev.c
+dfile.c
+dlsof.h
+dmnt.c
+dnode.c
+dnode1.c
+dnode2.c
+dproc.c
+dproto.h
+dsock.c
+dstore.c
+machine.h
+solaris_kaddr_filters
+
+./dialects/uw:
+Makefile
+Mksrc*
+dfile.c
+dlsof.h
+dmnt.c
+dnode.c
+dnode1.c
+dnode2.c
+dnode3.c
+dproc.c
+dproto.h
+dsock.c
+dstore.c
+machine.h
+uw7/
+
+./dialects/uw/uw7:
+README
+fs/
+sys/
+vm/
+
+./dialects/uw/uw7/fs:
+nsc_cfs/
+procfs/
+
+./dialects/uw/uw7/fs/nsc_cfs:
+cnode.h
+
+./dialects/uw/uw7/fs/procfs:
+README
+prdata.h
+
+./dialects/uw/uw7/sys:
+fs/
+
+./dialects/uw/uw7/sys/fs:
+README
+fifonode.h
+namenode.h
+
+./dialects/uw/uw7/vm:
+
+./lib:
+Makefile.skel
+ckkv.c
+cvfs.c
+dvch.c
+fino.c
+isfn.c
+lkud.c
+pdvn.c
+prfp.c
+ptti.c
+rdev.c
+regex.c
+rmnt.c
+rnam.c
+rnch.c
+rnmh.c
+snpf.c
+
+./scripts:
+00MANIFEST
+00README
+big_brother.perl5*
+count_pf.perl*
+count_pf.perl5*
+identd.perl5*
+idrlogin.perl*
+idrlogin.perl5*
+list_NULf.perl5*
+list_fields.awk
+list_fields.perl*
+shared.perl5*
+sort_res.perl5*
+watch_a_file.perl*
+xusers.awk*
+
+./tests:
+00README
+Add2TestDB*
+CkTestDB*
+LTbasic.c
+LTbigf.c
+LTdnlc.c
+LTlib.c
+LTlock.c
+LTnfs.c
+LTnlink.c
+LTsock.c
+LTszoff.c
+LTunix.c
+LsofTest.h
+Makefile
+TestDB
diff --git a/00PORTING b/00PORTING
new file mode 100644
index 0000000..2683946
--- /dev/null
+++ b/00PORTING
@@ -0,0 +1,1838 @@
+
+		Guide to Porting lsof 4 to Unix OS Dialects
+
+**********************************************************************
+| The latest release of lsof is always available via anonymous ftp   |
+| from lsof.itap.purdue.edu.  Look in pub/lsof.README for its        |
+| location.                                                          |
+**********************************************************************
+
+			    Contents
+
+	How Lsof Works
+	/proc-based Linux Lsof -- a Different Approach
+	General Guidelines
+	Organization
+	Source File Naming Conventions
+	Coding Philosophies
+	Data Requirements
+	Dlsof.h and #include's
+	Definitions That Affect Compilation
+	Options: Common and Special
+	Defining Dialect-Specific Symbols and Global Storage
+	Coding Dialect-specific Functions
+	Function Prototype Definitions and the _PROTOTYPE Macro
+	The Makefile
+	The Mksrc Shell Script
+	The MkKernOpts Shell Script
+	Testing and the lsof Test Suite
+	Where Next?
+
+
+How Lsof Works
+--------------
+
+Before getting on with porting guidelines, just a word or two about
+how lsof works.
+
+Lsof obtains data about open UNIX dialect files by reading the
+kernel's proc structure information, following it to the related
+user structure, then reading the open file structures stored
+(usually) in the user structure.  Typically lsof uses the kernel
+memory devices, /dev/kmem, /dev/mem, etc. to read kernel data.
+
+Lsof stores information from the proc and user structures in an
+internal, local proc structure table.  It then processes the open
+file structures by reading the file system nodes that lie behind
+them, extracting and storing relevant data in internal local file
+structures that are linked to the internal local process structure.
+
+Once all data has been gathered, lsof reports it from its internal,
+local tables.
+
+There are a few variants on this subject.  Some systems don't have
+just proc structures, but have task structures, too, (e.g., NeXTSTEP
+and OSF/1 derivatives).  For some dialects lsof gets proc structures
+or process information (See "/proc-based Linux Lsof -- a Different
+Approach) from files of the /proc file system.  It's not necessary
+for lsof to read user structures on some systems (recent versions
+of HP-UX), because the data lsof needs can be found in the task or
+proc structures.  In the end lsof gathers the same data, just from
+slightly different sources.
+
+
+/proc-based Linux Lsof -- a Different Approach
+==============================================
+
+For a completely different approach to lsof construction, take a
+look at the /proc-based Linux sources in .../dialects/linux/proc.
+(The sources in .../dialects/linux/kmem are for a traditional lsof
+that uses /dev/kmem to read information from kernel structures.)
+
+The /proc-based lsof obtains all its information from the Linux
+/proc file system.  Consequently, it is relatively immune to changes
+in Linux kernel structures and doesn't need to be re-compiled each
+time the Linux kernel version changes.
+
+There are some down-sides to the Linux /proc-based lsof:
+
+    *  It must run setuid-root in order to be able to read the
+       /proc file system branches for all processes.  In contrast,
+       the /dev/kmem-based Linux lsof usually needs only setgid
+       permission.
+
+    *  It depends on the exact character format of /proc files, so
+       it is sensitive to changes in /proc file composition.
+
+    *  It is limited to the information a /proc file system
+       implementor decides to provide.  For example, if a
+       /proc/net/<protocol> file lacks an inode number, the
+       /proc-based lsof can't connect open socket files to that
+       protocol.  Another deficiency is that the /proc-based may
+       not be able to report file offset (position) information,
+       when it isn't available in the /proc/<PID>/fd/ entry for a
+       file.
+
+       In contrast the /dev/kmem-based lsof has full access to
+       kernel structures and "sees" new data as soon as it appears.
+       Of course, that new data requires that lsof be recompiled
+       and usually also requires changes to lsof.
+
+Overall the switch from a /dev/kmem base to a /proc one is an
+advantage to Linux lsof.  The switch was made at lsof revision 4.23
+for Linux kernel versions 2.1.72 (approximately) and higher.  The
+reason I'm not certain at which Linux kernel version a /proc-based
+lsof becomes possible is that the /proc additions needed to implement
+it have been added gradually to Linux 2.1.x in ways that I cannot
+measure.
+
+/proc-based lsof functions in many ways the same as /dev/kmem-based
+lsof.  It scans the /proc directory, looking for <PID>/ subdirectories.
+Inside each one it collects process-related data from the cwd, exe,
+maps, root, and stat information files.
+
+It collects open file information from the fd/ subdirectory of each
+<PID>/ subdirectory.  The lstat(2), readlink(2), and stat(2) system
+calls gather information about the files from the kernel.
+
+Lock information comes from /proc/locks.  It is matched to open
+files by inode number.  Mount information comes from /proc/mounts.
+Per domain protocol information comes from the files of /proc/net;
+it's matched to open socket files by inode number.
+
+The Linux /proc file system implementors have done an amazing job
+of providing the information lsof needs.  The /proc-based lsof
+project has so far generated only two kernel modification:
+
+    *  A modification to /usr/src/linux/net/ipx/af_ipx.c adds the
+       inode number to the entries of /proc/net/ipx.
+
+       Jonathan Sergent did this kernel modification.
+
+       It may be found in the .../dialects/linux/proc/patches
+       subdirectory of the lsof distribution.
+
+    *  An experimental modification to /usr/src/linux/fs/stat.c
+       allows lstat(2) to return file position information for
+       /proc/<PID>/fd/<FD> files.
+       
+       Contact me for this modification.
+
+
+One final note about the /proc-based Linux lsof: it doesn't need
+any functions from the lsof library in the lib/ subdirectory.
+
+
+General Guidelines
+------------------
+
+These are the general guidelines for porting lsof 4 to a new Unix
+dialect:
+
+    *  Understand the organization of the lsof sources and the
+       philosophies that guide their coding.
+
+    *  Understand the data requirements and determine the methods
+       of locating the necessary data in the new dialect's kernel.
+
+    *  Pick a name for the subdirectory in lsof4/dialects for your
+       dialect.  Generally I use a vendor operating system name
+       abbreviation.
+
+    *  Locate the necessary header files and #include them in the
+       dialect's dlsof.h file.  (You may not be able to complete
+       this step until you have coded all dialect-specific functions.)
+
+    *  Determine the optional library functions of lsof to be used
+       and set their definitions in the dialect's machine.h file.
+
+    *  Define the dialect's specific symbols and global storage
+       in the dialect's dlsof.h and dstore.c files.
+
+    *  Code the dialect-specific functions in the appropriate
+       source files of the dialect's subdirectory.
+
+       Include the necessary prototype definitions of the dialect-
+       specific functions in the dproto.h file in the dialect's
+       subdirectory.
+
+    *  Define the dialect's Makefile and source construction shell
+       script, Mksrc.
+
+    *  If there are #define's that affect how kernel structures
+       are organized, and those #define's are needed when compiling
+       lsof, build a MkKernOpts shell script to locate the #define's
+       and supply them to the Configure shell script.
+
+
+Organization
+------------
+
+The code in a dialect-specific version of lsof comes from three
+sources:
+
+    1)  functions common to all versions, located in the top level
+	directory, lsof4;
+
+    2)  functions specific to the dialect, located in the dialect's
+	subdirectory -- e.g., lsof4/dialects/sun;
+
+    3)  functions that are common to several dialects, although
+	not to all, organized in a library, liblsof.a.  The functions
+	in the library source can be selected and customized with
+	definitions in the dialect machine.h header files.
+
+The tree looks like this:
+
+			    lsof4 ----------------------+ 3) library --
+			    |   \			     lsof4/lib
+  1) fully common functions +    \
+      e.g., lsof4/main.c	  + lsof4/dialects/
+			   / / / / \
+			   + + + +  +
+  2) dialect-specific subdirectories -- e.g., lsof4/dialects/sun
+
+The code for a dialect-specific version is constructed from these
+three sources by the Configure shell script in the top level lsof4
+directory and definitions in the dialect machine.h header files.
+Configure uses the Mksrc shell script in each dialect's subdirectory,
+and may use an optional MkKernOpts shell script in selected dialect
+subdirectories.
+
+Configure calls the Mksrc shell script in each dialect's subdirectory
+to assemble the dialect-specific sources in the main lsof directory.
+Configure may call MkKernOpts to determine kernel compile-time
+options that are needed for compiling kernel structures correctly
+for use by lsof.  Configure puts the options in a dialect-specific
+Makefile it build, using a template in the dialect subdirectory.
+
+The assembly of dialect-specific sources in the main lsof directory
+is usually done by creating symbolic links from the top level to
+the dialect's subdirectory.  The LSOF_MKC environment variable may
+be defined prior to using Configure to change the technique used
+to assemble the sources -- most commonly to use cp instead of ln -s.
+
+The Configure script completes the dialect's Makefile by adding
+string definitions, including the necessary kernel compile-time
+options, to a dialect skeleton Makefile while copying it from the
+dialect subdirectory to the top level lsof4 directory.  Optionally
+Makefile may call the dialect's MkKernOpts script to add string
+definitions.
+
+When the lsof library, lsof4/lib/liblsof.a, is compiled its
+functions are selected and customized by #define's in the dialect
+machine.h header file.
+
+
+Source File Naming Conventions
+------------------------------
+
+With one exception, dialect-specific source files begin with a
+lower case `d' character -- ddev.c, dfile.c, dlsof.h.  The one
+exception is the header file that contains dialect-specific
+definitions for the optional features of the common functions.
+It's called machine.h for historical reasons.
+
+Currently all dialects use almost the same source file names.  One
+exception to the rule happens in dialects where there must be
+different source files -- e.g., dnode[123].c -- to eliminate node
+header file structure element name conflicts.  The source modules
+in a few subdirectories are organized that way.
+
+Unusual situations occur for NetBSD and OpenBSD, and for NEXTSTEP
+and OPENSTEP.  Each pair of dialects is so close in design that
+the same dialect sources from the n+obsd subdirectory serves NetBSD
+and OpenBSD; from n+os, NEXTSTEP and OPENSTEP.
+
+These are common files in lsof4/:
+
+    Configure	the configuration script
+
+    Customize	does some customization of the selected lsof
+		dialect
+
+    Inventory	takes an inventory of the files in an lsof
+		distribution
+
+    version	the version number
+
+    dialects/	the dialects subdirectory
+
+These are the common function source files in lsof4/:
+
+    arg.c	common argument processing functions
+
+    lsof.h	common header file that #include's the dialect-specific
+		header files
+
+    main.c	common main function for lsof 4
+
+    misc.c	common miscellaneous functions -- e.g., special versions
+		of stat() and readlink()
+
+    node.c	common node reading functions -- readinode(), readvnode()
+
+    print.c	common print support functions
+
+    proc.c	common process and file structure functions
+
+    proto.h	common prototype definitions, including the definition of
+		the _PROTOTYPE() macro
+
+    store.c	common global storage version.h	the current lsof version
+		number, derived from the file version by the Makefile
+
+    usage.c	functions to display lsof usage panel
+
+These are the dialect-specific files:
+
+    Makefile	the Makefile skeleton
+
+    Mksrc	a shell script that assists the Configure script
+		in configuring dialect sources
+
+    MkKernOpts  an optional shell script that identifies kernel
+		compile-time options for selected dialects -- e.g.,
+		Pyramid DC/OSx and Reliant UNIX
+
+    ddev.c	device support functions -- readdev() -- may be
+		eliminated by functions from lsof4/lib/
+
+    dfile.c	file processing functions -- may be eliminated by
+		functions from lsof4/lib/
+
+    dlsof.h	dialect-specific header file -- contains #include's
+		for system header files and dialect-specific global
+		storage declarations
+
+    dmnt.c	mount support functions -- may be eliminated by
+		functions from lsof4/lib/
+
+    dnode.c	node processing functions -- e.g., for gnode or vnode
+
+    dnode?.c	additional node processing functions, used when node
+		header files have duplicate and conflicting element
+		names.
+
+    dproc.c	functions to access, read, examine and cache data about
+		dialect-specific process structures -- this file contains
+		the dialect-specific "main" function, gather_proc_info()
+
+    dproto.h	dialect-specific prototype declarations
+
+    dsock.c	dialect-specific socket processing functions
+
+    dstore.c	dialect-specific global storage -- e.g., the nlist()
+		structure
+
+    machine.h	dialect specific definitions of common function options --
+		e.g., a HASINODE definition to activate the readinode()
+		function in lsof4/node.c
+
+		The machine.h header file also selects and customizes
+		the functions of lsof4/lib/.
+
+These are the lib/ files.  Definitions in the dialect machine.h
+header files select and customize the contained functions that are
+to be compiled and archived to liblsof.a.
+
+    Makefile.skel	is a skeleton Makefile, used by Configure
+			to construct the Makefile for the lsof
+			library.
+
+    cvfs.c		completevfs() function
+
+			USE_LIB_COMPLETEVFS selects it.
+
+			CVFS_DEVSAVE, CVFS_NLKSAVE, CVFS_SZSAVE,
+			and HASFSINO customize it.
+
+    dvch.c		device cache functions
+
+			HASDCACHE selects them.
+
+			DCACHE_CLONE, DCACHE_CLR, DCACHE_PSEUDO,
+			DVCH_CHOWN, DVCH_DEVPATH, DVCH_EXPDEV,
+			HASBLKDEV, HASENVDC, HASSYSDC, HASPERSDC,
+			HASPERSDCPATH, and NOWARNBLKDEV customize
+			them.
+
+    fino.c		find block and character device inode functions
+
+			HASBLKDEV and USE_LIB_FIND_CH_INO select them.
+
+    isfn.c		hashSfile() and is_file_named() functions
+
+			USE_LIB_IS_FILE_NAMED selects it.
+
+    lkud.c		device lookup functions
+
+			HASBLKDEV and USE_LIB_LKUPDEV select them.
+
+    pdvn.c		print device name functions
+
+			HASBLKDEV and USE_LIB_PRINTDEVNAME select them.
+
+    prfp.c		process_file() function
+
+			USE_LIB_PROCESS_FILE selects it.
+
+			FILEPTR, DTYPE_PIPE, HASPIPEFN, DTYPE_GNODE,
+			DTYPE_INODE, DTYPE_PORT, DTYPE_VNODE,
+			HASF_VNODE, HASKQUEUE, HASPRIVFILETYPE,
+			HASPSXSHM and HASPSXSEM customize it.
+
+    ptti.c		print_tcptpi() function
+
+			USE_LIB_PRINT_TCPTPI selects it.
+
+			HASSOOPT, HASSBSTATE, HASSOSTATE, AHSTCPOPT,
+			HASTCPTPIQ and HASTCPTPIW customize it.
+
+    rdev.c		readdev() function
+
+			USE_LIB_READDEV selects it.
+
+			DIRTYPE, HASBLKDEV, HASDCACHE, HASDNAMLEN,
+			RDEV_EXPDEV, RDEV_STATFN, USE_STAT, and
+			WARNDEVACCESS customize it.
+
+    rmnt.c		readmnt() function
+
+			USE_LIB_READMNT selects it.
+
+			HASFSTYPE, MNTSKIP, RMNT_EXPDEV, RMNT_FSTYPE,
+			and MOUNTS_FSTYPE customize it.
+
+    rnam.c		BSD format name cache functions
+
+			HASNCACHE and USE_LIB_RNAM select them.
+
+			HASFSINO, NCACHE, NCACHE_NC_CAST, NCACHE_NM,
+			NCACHE_NMLEN, NCACHE_NODEADDR, NCACHE_NODEID,
+			NCACHE_NO_ROOT, NCACHE_NXT, NCACHE_PARADDR,
+			NCACHE_PARID, NCACHE_SZ_CAST, NCHNAMLEN,
+			X_NCACHE, and X_NCSIZE, customize them.
+
+    rnch.c		Sun format name cache functions
+
+			HASNCACHE and USE_LIB_RNCH select them.
+
+			ADDR_NCACHE, HASDNLCPTR, HASFSINO, NCACHE_DP,
+			NCACHE_NAME, NCACHE_NAMLEN, NCACHE_NEGVN,
+			NCACHE_NODEID, NCACHE_NXT, NCACHE_PARID,
+			NCACHE_VP, X_NCACHE, and X_NCSIZE, customize
+			them.
+
+    snpf.c		Source for the snprintf() family of functions
+
+			USE_LIB_SNPF selects it.
+
+
+The comments and the source code in these library files give more
+information on customization.
+
+
+Coding Philosophies
+-------------------
+
+A few basic philosophies govern the coding of lsof 4 functions:
+
+    *  Use as few #if/#else/#endif constructs as possible, even at
+       the cost of nearly-duplicate code.
+
+       When #if/#else/#endif constructs are necessary:
+       
+       o  Use the form
+
+		#if	defined(s<symbol>)
+	
+	  in preference to
+	
+		#ifdef	<symbol>
+	
+	  to allow easier addition of tests to the #if.
+
+       o  Indent them to signify their level -- e.g.,
+
+		#if	/* level one */
+		# if	/* level two */
+		# endif	/* level two */
+		#else	/* level one */
+		#endif	/* level one */
+
+	o  Use ANSI standard comments on #else and #endif statements.
+
+    *  Document copiously.
+
+    *  Aim for ANSI-C compatibility:
+    
+       o  Use function prototypes for all functions, hiding them
+	  from compilers that cannot handle them with the _PROTOTYPE()
+	  macro.
+
+       o  Use the compiler's ANSI conformance checking wherever
+	  possible -- e.g., gcc's -ansi option.
+
+
+Data Requirements
+-----------------
+
+Lsof's strategy in obtaining open file information is to access
+the process table via its proc structures, then obtain the associated
+user area and open file structures.  The open file structures then
+lead lsof to file type specific structures -- cdrnodes, fifonodes,
+inodes, gnodes, hsfsnodes, pipenodes, pcnodes, rnodes, snodes,
+sockets, tmpnodes, and vnodes.
+
+The specific node structures must yield data about the open files.  The
+most important items and device number (raw and cooked) and node
+number.  (Lsof uses them to identify files and file systems named as
+arguments.)  Link counts and file sizes are important, too, as are the
+special characteristics of sockets, pipes, FIFOs, etc.
+
+This means that to begin an lsof port to a new Unix dialect you
+must understand how to obtain these structures from the dialect's
+kernel.  Look for kernel access functions -- e.g., the AIX readx()
+function, Sun and Sun-like kvm_*() functions, or SGI's syssgi()
+function.  Look for clues in header files -- e.g. external declarations
+and macros.
+
+If you have access to them, look at sources to programs like ps(1),
+or the freely available monitor and top programs.  They may give
+you important clues on reading proc and user area structures.  An
+appeal to readers of dialect-specific news groups may uncover
+correspondents who can help.
+
+Careful reading of system header files -- e.g., <sys/proc.h> --
+may give hints about how kernel storage is organized.  Look for
+global variables declared under a KERNEL or _KERNEL #if.  Run nm(1)
+across the kernel image (/vmunix, /unix, etc.) and look for references
+to structures of interest.
+
+Even if there are support functions for reading structures, like the
+kvm_*() functions, you must still understand how to read data from
+kernel memory.  Typically this requires an understanding of the
+nlist() function, and how to use /dev/kmem, /dev/mem, and /dev/swap.
+
+Don't overlook the possibility that you may have to use the process
+file system -- e.g., /proc.  I try to avoid using /proc when I can,
+since it usually requires that lsof have setuid(root) permission
+to read the individual /proc "files".
+
+Once you can access kernel structures, you must understand how
+they're connected.  You must answer questions like:
+
+    *  How big are kernel addresses?  How are they type cast?
+
+    *  How are kernel variable names converted to addresses?
+       Nlist()?
+
+    *  How are the proc structures organized?  Is it a static
+       table?  Are the proc structures linked?  Is there a
+       kernel pointer to the first proc structure?  Is there a
+       proc structure count?
+
+    *  How does one obtain copies of the proc structures?  Via
+       /dev/kmem?  Via a vendor API?
+
+    *  If this is a Mach derivative, is it necessary to obtain the
+       task and thread structures?  How?
+
+    *  How does one obtain the user area (or the utask area in Mach
+       systems) that corresponds to a process?
+
+    *  Where are the file structures located for open file
+       descriptors and how are they located?  Are all file
+       structures in the user area?  Is the file structure space
+       extensible?
+
+    *  Where do the private data pointers in file structures lead?
+       To gnodes?  To inodes?  To sockets?  To vnodes?  Hint: look
+       in <sys/file.h> for DTYPE_* instances and further pointers.
+
+    *  How are the nodes organized?  To what other nodes do they
+       lead and how?  Where are the common bits of information in
+       nodes -- device, node number, size -- stored?  Hint: look
+       in the header files for nodes for macros that may be used
+       to obtain the address of one node from another -- e.g., the
+       VTOI() macro that leads from a vnode to an inode.
+
+    *  Are text reference nodes identified and how?  Is it
+       necessary to examine the virtual memory map of a process or
+       a task to locate text references?  Some kernels have text
+       node pointers in the proc structures; some, in the user
+       area; Mach kernels may have text information in the task
+       structure, reached in various ways from the proc, user area,
+       or user task structure.
+
+    *  How is the device table -- e.g., /dev or /devices --
+       organized?  How is it read?  Using direct or dirent structures?
+
+       How are major/minor device numbers represented?  How are
+       device numbers assembled and disassembled?
+
+       Are there clone devices?  How are they identified?
+
+    *  How is mount information obtained?  Getmntinfo()?  Getmntent()?
+       Some special kernel call?
+
+    *  How are sockets identified and organized?  BSD-style?  As
+       streams?  Are there streams?
+
+    *  Are there special nodes -- CD-ROM nodes, FIFO nodes, etc.?
+
+    *  How is the kernel's name cache organized?  Can lsof access
+       it to get partial name components?
+
+
+Dlsof.h and #include's
+----------------------
+
+Once you have identified the kernel's data organization and know
+what structures it provides, you must add #include's to dlsof.h to
+access their definitions.  Sometimes it is difficult to locate the
+header files -- you may need to introduce -I specifications in the
+Makefile via the DINC shell variable in the Configure script.
+
+Sometimes it is necessary to define special symbols -- e.g., KERNEL,
+_KERNEL, _KMEMUSER -- to induce system header files to yield kernel
+structure definitions.  Sometimes making those symbol definitions
+cause other header file and definition conflicts.  There's no good
+general rule on how to proceed when conflicts occur.
+
+Rarely it may be necessary to extract structure definitions from
+system header files and move them to dlsof.h, create special versions
+of system header files, or obtain special copies of system header
+files from "friendly" (e.g., vendor) sources.  The dlsof.h header
+file in lsof4/dialects/sun shows examples of the first case; the
+second, no examples; the third, the irix5hdr subdirectory in
+lsof4/dialects/irix (a mixture of the first and third).
+
+Building up the necessary #includes in dlsof.h is an iterative
+process that requires attention as you build the dialect-specific
+functions that references kernel structures.  Be prepared to revisit
+dlsof.h frequently.
+
+
+Definitions That Affect Compilation
+-----------------------------------
+
+The source files at the top level and in the lib/ subdirectory
+contain optional functions that may be activated with definitions
+in a dialect's machine.h header file.  Some are functions for
+reading node structures that may not apply to all dialects -- e.g.
+CD-ROM nodes (cdrnode), or `G' nodes (gnode) -- and others are
+common functions that may occasionally be replaced by dialect-specific
+ones.  Once you understand your kernel's data organization, you'll
+be able to decide the optional common node functions to activate.
+
+Definitions in machine.h and dlsof.h also enable or disable other
+optional common features.  The following is an attempt to list all
+the definitions that affect lsof code, but CAUTION, it is only
+attempt and may be incomplete.  Always check lsof4 source code in
+lib/ and dialects/, and dialect machine.h header files for other
+possibilities
+
+    AFS_VICE		See 00XCONFIG.
+
+    AIX_KERNBITS	specifies the kernel bit size, 32 or 64, of the Power
+			architecture AIX 5.x kernel for which lsof was built.
+
+    CAN_USE_CLNT_CREATE	is defined for dialects where the more modern
+			RPC function clnt_create() can be used in
+			place of the deprecated clnttcp_create().
+
+    CLONEMAJ            defines the name of the variable that
+			contains the clone major device number.
+			(Also see HAS_STD_CLONE and HAVECLONEMAJ.)
+
+    DEVDEV_PATH		defines the path to the directory where device
+			nodes are stored, usually /dev.  Solaris 10
+			uses /devices.
+
+    DIALECT_WARNING	may be defined by a dialect to provide a
+			warning message that will be displayed with
+			help (-h) and version (-v) output.
+
+    FSV_DEFAULT		defines the default file structure values to
+			list.  It may be composed of or'd FSV_*
+			(See lsof.h) values.  The default is none (0).
+
+    GET_MAJ_DEV         is a macro to get major portion from device
+			number instead of via the standard major()
+			macro.
+
+    GET_MIN_DEV		is a macro to get minor portion from device
+			number instead of via the standard minor()
+			macro.
+
+    GET_MAX_FD		the name of the function that returns an
+			int for the maximum open file descriptor
+			plus one.  If not defined, defaults to
+			getdtablesize.
+
+    HAS9660FS           enables CD9660 file system support in a
+			BSD dialect.
+
+    HAS_ADVLOCK_ARGS    is defined for NetBSD and OpenBSD dialects
+			whose <sys/lockf.h> references vop_advlock_args.
+
+    HAS_AFS		enables AFS support code for the dialect.
+
+    HAS_ATOMIC_T	indicates the Linux version has an
+			<asm/atomic.h> header file and it contains
+			"typedef struct .* atomic_t;"
+
+    HASAOPT		indicates the dialect supports the AFS -A
+			option when HAS_AFS is also defined.
+
+    HAS_ASM_TERMIOBITS  indicates for Linux Alpha that the
+			<asm/termiobits.h> header file exists.
+
+    HASAX25CBPTR	indicates that the Linux sock struct has an
+			ax25_db pointer.
+
+    HASBLKDEV		indicates the dialect has block device support.
+
+    HASBUFQ_H		indicates the *NSD dialect has the <sys/bufq.h>
+			header file.
+
+    HASCACHEFS		enables cache file system support for the
+			dialect.
+
+    HAS_CDFS		enables CDFS file system support for the
+			dialect.
+
+    HASCDRNODE		enables/disables readcdrnode() in node.c.
+
+    HAS_CONN_NEW        indicates the Solaris version has the new form
+			of the conn_s structure, introduced in b134 of
+			Solaris 11.  This will always accompany the
+			HAS_IPCLASSIFIER_H definition.
+
+    HAS_CONST		indicates that the compiler supports the
+			const keyword.
+
+    HASCPUMASK_T	indicates the FreeBSD 5.2 or higher dialect
+			has cpumask_t typedef's.
+
+    HAS_CRED_IMPL_H	indicates the Solaris 10 dialect has the
+			<sys/cred_impl.h> header file available.
+
+    HASCWDINFO          indicates the cwdinfo structure is defined
+			in the NetBSD <sys/filedesc.h>.
+
+    HASDCACHE           enables device file cache file support.
+			The device cache file contains information
+			about the names, device numbers and inode
+			numbers of entries in the /dev (or /device)
+			node subtree that lsof saves from call to
+			call.  See the 00DCACHE file of the lsof
+			distribution for more information on this
+			feature.
+
+    HASDENTRY		indicates the Linux version has a dentry
+			struct defined in <linux/dcache.h>.
+
+    HASDEVKNC           indicates the Linux version has a kernel
+			name cached keyed on device number.
+
+    HAS_DINODE_U	indicates the OpenBSD version has a dinode_u
+			union in its inode structure.
+
+    HASDNLCPTR          is defined when the name cache entry of
+			<sys/dnlc.h> has a name character pointer
+			rather than a name character array.
+
+    HASEFFNLINK		indicates the *BSD system has the i_effnlink
+			member in the inode structure.
+
+    HASENVDC            enables the use of an environment-defined
+			device cache file path and defines the name
+			of the environment variable from which lsof
+			may take it.  (See the 00DCACHE file of
+			the lsof distribution for information on
+			when HASENVDC is used or ignored.)
+
+    HASEOPT		indicates the dialect supports the -e option to
+			eliminate kernel blocks on a named file system.
+
+    HASEXT2FS           is defined for BSD dialects for which ext2fs
+			file system support can be provided.  A value
+			of 1 indicates that the i_e2din member does not
+			exist; 2, it exists.
+
+    HASF_VNODE		indicates the dialect's file structure has an
+			f_vnode member in it.
+
+    HASFDESCFS		enables file descriptor file system support
+			for the dialect.   A value of 1 indicates
+			<miscfs/fdesc.h> has a Fctty definition; 2,
+			it does not.
+
+    HASFDLINK		indicates the file descriptor file system
+			node has the fd_link member.
+
+    HASFIFONODE		enables/disables readfifonode() in node.c.
+
+    HAS_FL_FD		indicates the Linux version has an fl_fd
+			element in the lock structure of <linux/fs.h>.
+
+    HAS_FL_FILE		indicates the Linux version has an fl_file
+			element in the lock structure of <linux/fs.h>.
+
+    HAS_FL_WHENCE	indicates the Linux version has an fl_whence
+			element in the lock structure of <linux/fs.h>.
+
+    HAS_F_OPEN		indicates the UnixWare 7.x dialect has the
+			f_open member in its file struct.
+
+    HASFSINO            enables the inclusion of the fs_ino element
+			in the lfile structure definition in lsof.h.
+			This contains the file system's inode number
+			and may be needed when searching the kernel
+			name cache.  See dialects/osr/dproc.c for
+			an example.
+
+    HAS_JFS2		The AIX >= 5.0 dialect has jfs2 support.
+
+    HASFSTRUCT		indicates the dialect has a file structure
+			the listing of whose element values can be
+			enabled with +f[cfn].  FSV_DEFAULT defines
+			the default listing values.
+
+    HASFSTYPE           enables/disables the use of the file system's
+			stat(2) st_fstype member.
+
+			If the HASFSTYPE value is 1, st_fstype is
+			treated as a character array; 2, it is
+			treated as an integer.
+
+			See also the RMNT_EXPDEV and RMNT_FSTYPE
+			documentation in lib/rmnt.c
+
+    HASGETBOOTFILE	indicates the NetBSD or OpenBSD dialect has
+			a getbootfile() function.
+
+    HASGNODE		enables/disables readgnode() in node.c.
+
+    HASHASHPID		is defined when the Linux version (probably
+			above 2.1.35) has a pidhash_next member in
+			its task structure.
+
+    HASHSNODE		enables/disables readhsnode() in node.c.
+
+    HASI_E2FS_PTR	indicates the BSD dialect has a pointer in
+			its inode to the EXTFS dinode.
+
+    HASI_FFS            indicates the BSD dialect has i_ffs_size
+			in <ufs/ufs/inode.h>.
+
+    HASI_FFS1		indicates the BSD dialect supports the fast
+			UFS1 and UFS2 file systems.
+
+    HAS_INKERNEL        indicates the SCO OSR 6.0.0 or higher, or
+			UnixWare 7.1.4 or higher system uses the
+			INKERNEL symbol in <netinet/in_pcb.h> or
+			<netinet/tcp_var.h>.
+
+    HASINODE		enables/disables readinode() in node.c.
+
+    HASINOKNC		indicates the Linux version has a kernel
+			name cache keyed on inode address.
+
+    HASINADDRSTR	is defined when the inp_[fl]addr members
+			of the inpcb structure are structures.
+
+    HASINRIAIPv6	is defined if the dialect has the INRIA IPv6
+			support.  (HASIPv6 will also be defined.)
+
+    HASINT16TYPE	is defined when the dialect has a typedef
+			for int16 that may conflict with some other
+			header file's redefinition (e.g., <afs/std.h>).
+
+    HASINT32TYPE	is defined when the dialect has a typedef
+			for int32 that may conflict with some other
+			header file's redefinition (e.g., <afs/std.h>).
+
+    HASINTSIGNAL	is defined when signal() returns an int.
+
+    HAS_IPCLASSIFIER_H	is defined for Solaris dialects that have the
+			<inet/ipclassifier.h> header file.
+
+    HAS_IPC_S_PATCH	is defined when the HP-UX 11 dialect has the
+			ipc_s patch installed.  It has a value of
+			1 if the ipc_s structure has an ipc_ipis
+			member, but the ipis_s structure lacks the
+			ipis_msgsqueued member; 2, if ipc_s has
+			ipc_ipis, but ipis_s lacks ipis_msgsqueued.
+
+    HASIPv6             indicates the dialect supports the IPv6
+			Internet address family.
+
+    HASKERNELKEYT       indicates the Linux version has a
+			__kernel_key_t typedef in <linux/types.h>.
+
+    HASKERNFS           is defined for BSD dialects for which
+			/kern file system support can be provided.
+
+    HASKERNFS_KFS_KT	indicates *kfs_kt is in the BSD dialect's
+			<miscfs/kernfs/kernfs.h>.
+
+    HASKOPT		enables/disables the ability to read the
+			kernel's name list from a file -- e.g., from
+			a crash dump file.
+
+    HASKQUEUE           indicates the dialect supports the kqueue
+			file type.
+
+    HASKVMGETPROC2      The *BSD dialect has the kvm_gettproc2()
+			function.
+
+    HAS_KVM_VNODE	indicates the FreeBSD 5.3 or higher dialect has
+			"defined(_KVM_VNODE)" in <sys/vnode.h>.
+
+    HASLFILEADD		defines additional, dialect-specific elements
+    SETLFILEADD		in the lfile structure (defined in lsof.h).
+			HASLFILEADD is a macro. The accompanying SETFILEADD
+			macro is used in the alloc_lfile() function of
+			proc.c to preset the additional elements.
+
+    HAS_LF_LWP          is defined for BSD dialects where the lockf
+			structure has an lf_lwp member.
+
+    HASLFS		indicates the *BSD dialect has log-structured
+			file system support.
+
+    HAS_LGRP_ROOT_CONFLICT
+			indicates the Solaris 9 or Solaris 10 system has 
+			a conflict over the lgrp_root symbol in the
+			<sys/lgrp.h> and <sys/lgrp_user.h> header files.
+
+    HAS_LIBCTF		indicates the Solaris 10 and above system has
+			the CTF library.
+
+    HAS_LOCKF_ENTRY	indicates the FreeBSD version has a lockf_entry
+			structure in its <sys/lockf.h> header file.
+
+    HAS_LWP_H		is defined for BSD dialects that have the
+			<sys/lwp.h> header file.
+
+    HASMOPT		enables/disables the ability to read kernel
+			memory from a file -- e.g., from a crash
+			dump file.
+
+    HASMSDOSFS		enables MS-DOS file system support in a
+			BSD dialect.
+
+    HASMNTSTAT          indicates the dialect has a stat(2) status
+			element in its mounts structure.
+
+    HASMNTSUP		indicates the dialect supports the mount supplement
+			option.
+
+    HASNAMECACHE	indicates the FreeBSD dialect has a namecache
+			structure definition in <sys/namei.h>.
+
+    HASNCACHE		enables the probing of the kernel's name cache
+			to obtain path name components.  A value
+			of 1 directs printname() to prefix the
+			cache value with the file system directory
+			name; 2, avoid the prefix.
+
+    HASNCVPID           The *BSD dialect namecache struct has an
+			nc_vpid member.
+
+    HASNETDEVICE_H	indicates the Linux version has a netdevice.h
+			header file.
+
+    HAS_NFS		enables NFS support for the dialect.
+
+    HASNFSKNC		indicates the LINUX version has a separate
+			NFS name cache.
+
+    HASNFSPROTO         indicates the NetBSD or OpenBSD version
+			has the nfsproto.h header file.
+
+    HASNFSVATTRP	indicates the n_vattr member of the nfsnode of
+			the *BSD dialect is a pointer.
+
+    HASNLIST		enables/disables nlist() function support.
+			(See NLIST_TYPE.)
+
+    HASNOFSADDR		is defined if the dialect has no file structure
+			addresses.  (HASFSTRUCT must be defined.)
+
+    HASNOFSCOUNT	is defined if the dialect has no file structure counts.
+			(HASFSTRUCT must be defined.)
+
+    HASNOFSFLAGS	is defined if the dialect has no file structure flags.
+			(HASFSTRUCT must be defined.)
+
+    HASNOFSNADDR	is defined if the dialect has no file structure node
+			addresses.  (HASFSTRUCT must be defined.)
+
+    HAS_NO_6PORT	is defined if the FreeBSD in_pcb.h has no in6p_.port
+			definitions.
+
+    HAS_NO_6PPCB	is defined if the FreeBSD in_pcb.h has no in6p_ppcb
+			definition.
+
+    HAS_NO_ISO_DEV	indicates the FreeBSD 6 and higher system has
+			no i_dev member in its iso_node structure.
+
+    HAS_NO_LONG_LONG	indicates the dialect has no support for the C
+			long long type.  This definition is used by
+			the built-in snprintf() support of lib/snpf.c.
+
+    HASNORPC_H		indicates the dialect has no /usr/include/rpc/rpc.h
+			header file.
+
+    HAS_NO_SI_UDEV	indicates the FreeBSD 6 and higher system has
+			no si_udev member in its cdev structure.
+
+    HASNOSOCKSECURITY   enables the listing of open socket files,
+			even when HASSECURITY restricts listing of
+			open files to the UID of the user who is
+			running lsof, provided socket file listing
+			is selected with the "-i" option.  This
+			definition is only effective when HASSECURITY
+			is also defined.
+
+    HASNULLFS           indicates the dialect (usually *BSD) has a
+			null file system.
+
+    HASOBJFS            indicates the Pyramid version has OBJFS
+			support.
+
+    HASONLINEJFS	indicates the HP-UX 11 dialect has the optional
+			OnlineJFS package installed.
+
+    HAS_PC_DIRENTPERSEC
+			indicates the Solaris 10 system's <sys/fs/pc_node.h>
+			header file has the pc_direntpersec() macro.
+
+    HAS_PAD_MUTEX	indicates the Solaris 11 system has the pad_mutex_t
+			typedef in its <sys/mutex.h> header file.
+
+    HASPERSDC           enables the use of a personal device cache
+			file path and specifies a format by which
+			it is constructed.  See the 00DCACHE file
+			of the lsof distribution for more information
+			on the format.
+
+    HASPERSDCPATH       enables the use of a modified personal
+			device cache file path and specifies the
+			name of the environment variable from which
+			its component may be taken.  See the 00DCACHE
+			file of the lsof distribution for more
+			information on the modified personal device
+			cache file path.
+
+    HASPINODEN		declares that the inode number of a /proc file
+			should be stored in its procfsid structure.
+
+    HASPIPEFN           defines the function that processes DTYPE_PIPE
+			file structures.  It's used in the prfp.c
+			library source file.  See the FreeBSD
+			dialect source for an example.
+
+    HASPIPENODE		enables/disables readpipenode() in node.c.
+
+    HASPMAPENABLED      enables the automatic reporting of portmapper
+			registration information for TCP and UDP
+			ports that have been registered.
+
+    HASPPID		indicates the dialect has parent PID support.
+
+    HASPR_LDT		indicates the Solaris dialect has a pr_ldt
+			member in the pronodetype enum.
+
+    HASPR_GWINDOWS	indicates the Solaris dialect has a pr_windows
+			member in the pronodetype enum.
+
+    HASPRINTDEV         this value defines a private function for
+			printing the dialect's device number.  Used
+			by print.c/print_file().  Takes one argument:
+
+			char *HASPRINTDEV(struct lfile *)
+
+    HASPRINTINO         this value names a private function for
+			printing the dialect's inode number.  Used
+			by print.c/print_file(). Takes one argument:
+
+			char *HASPRINTINO(struct lfile *)
+
+    HASPRINTNM          this value names a private function for
+			printing the dialect's file name.  Used by
+			print.c/print_file().  Takes one argument:
+
+			void HASPRINTNM(struct lfile *)
+
+    HASPRINTOFF         this value names a private function for
+			printing the dialect's file offset.  Used
+			by print.c/print_file().  Takes two arguments:
+
+			char *HASPRINTOFF(struct lfile *, int ty)
+
+			Where ty == 0 if the offset is to be printed
+			in 0t<decimal> format; 1, 0x<hexadecimal>.
+
+    HASPRINTSZ		this value names a private function for
+			printing the dialect's file size.  Used
+			by print.c/print_file(). Takes one argument:
+
+			char *HASPRINTSZ(struct lfile *)
+
+			void HASPRINTNM(struct lfile *)
+
+    HASPRIVFILETYPE     enables processing of the private file
+			type, whose number (from f_type of the file
+			struct) is defined by PRIVFILETYPE.
+			HASPRIVFILETYPE defines the function that
+			processes the file struct's f_data member.
+			Processing is initiated from the process_file()
+			function of the prfp.c library source file
+			or from the dialect's own process_file()
+			function.
+
+    HASPRIVNMCACHE      enables printing of a file path from a
+			private name cache.  HASPRIVNMCACHE defines
+			the name of the printing function.  The
+			function takes one argument, a struct lfile
+			pointer to the file, and returns non-zero
+			if it prints a cached name to stdout.
+
+    HASPRIVPRIPP        is defined for dialects that have a private
+			function for printing the IP protocol name.
+			When this is not defined, the function to
+			do that defaults to printiproto().
+
+    HASPROCFS		defines the name (if any) of the process file
+			system -- e.g., /proc.
+
+    HASPROCFS_PFSROOT	indicates PFSroot is in the BSD dialect's
+			<miscfs/procfs/procfs.h>.
+
+    HASPSEUDOFS         indicates the FreeBSD dialect has pseudofs
+			file system support.
+
+    HASPSXSEM		indicates the dialect has support for the POSIX
+			semaphore file type.
+
+    HASPSXSHM		indicates the dialect has support for the POSIX
+			shared memory file type.
+
+    HASPTYFS		indicates the *BSD dialect has a ptyfs file system.
+
+    HASRNODE		enables/disables readrnode() in node.c.
+
+    HASRNODE3		indicates the HPUX 10.20 or lower dialect has NFS3
+			support with a modified rnode structure.
+
+    HASRPCV2H		The FreeBSD dialect has <nfs/rpcv2.h>.
+
+    HAS_SANFS           indicates the AIX system has SANFS file system
+			support.
+
+    HASSBSTATE          indicates the dialect has socket buffer state
+			information (e.g., SBS_* symbols) available.
+
+    HASSECURITY         enables/disables restricting open file
+			information access.  (Also see HASNOSOCKSECURITY.)
+
+    HASSELINUX          indicates the Linux dialect has SELinux security
+			context support available.
+
+    HASSETLOCALE	is defined if the dialect has <locale.h> and
+			setlocale().
+
+    HAS_SI_PRIV         indicates the FreeBSD 6.0 and higher cdev
+			structure has an si_priv member.
+
+    HAS_SOCKET_PROTO_H	indicates the Solaris 10 system has the header file
+			<sys/socket_proto.h>.
+
+    HASSOUXSOUA		indicates that the Solaris <sys/socketvar.h> has
+			soua_* members in its so_ux_addr structure.
+
+    HASSPECDEVD		indicates the dialect has a special device
+			directory and defines the name of a function
+			that processes the results of a successful
+			stat(2) of a file in that directory.
+
+    HASSPECNODE         indicates the DEC OSF/1, or Digital UNIX,
+			or Tru64 UNIX <sys/specdev.h> has a spec_node
+			structure definition.
+
+    HASSNODE		indicates the dialect has snode support.
+
+    HAS_SOCKET_SK	indicates that the Linux socket structure
+			has the ``struct sock *sk'' member.
+
+    HASSOOPT            indicates the dialect has socket option
+			information (e.g., SO_* symbols) available.
+
+    HASSOSTATE          indicates the dialect has socket state
+			information (e.g., SS_* symbols) available.
+
+    HASSTATVFS          indicates the NetBSD dialect has a statvfs
+			struct definition.
+
+    HASSTAT64		indicates the dialect's <sys/stat.h> contains
+			stat64.
+
+    HAS_STD_CLONE	indicates the dialect uses a standard clone
+			device structure that can be used in common
+			library function clone processing.  If the
+			value is 1, the clone table will be built
+			by readdev() and cached when HASDCACHE is
+			defined; if the value is 2, it is assumed
+			the clone table is built independently.
+			(Also see CLONEMAJ and HAVECLONEMAJ.)
+
+    HASSTREAMS          enables/disables streams.  CAUTION, requires
+			specific support code in the dialect sources.
+
+    HAS_STRFTIME	indicates the dialect has the gmtime() and
+			strftime() C library functions that support
+			the -r marker format option.  Configure tests
+			for the functions and defines this symbol.
+
+    HASSYSDC            enables the use of a system-wide device
+			cache file and defines its path.  See the
+			00DCACHE file of the lsof distribution for
+			more information on the system-wide device
+			cache file path option.
+
+    HAS_SYS_PIPEH	indicates the dialect has a <sys/pipe.h>
+			header file.
+
+    HAS_SYS_SX_H	indicates the FreeBSD 7.0 and higher system has
+			a <sys/sx.h> header file.
+
+    HASTAGTOPATH        indicates the DEC OSF/1, Digital UNIX, or
+			Tru64 UNIX dialect has a libmsfs.so,
+			containing tag_to_path().
+
+    HASTMPNODE		enables/disables readtnode() in node.c.
+
+    HASTCPOPT           indicates the dialect has TCP option
+			information (i.e., from TF_* symbols)
+			available.
+
+    HASTCPTPIQ          is defined when the dialect can duplicate
+			the receive and send queue sizes reported
+			by netstat.
+
+    HASTCPTPIW          is defined when the dialect can duplicate
+			the receive and send window sizes reported
+			by netstat.
+
+    HASTCPUDPSTATE	is defined when the dialect has support for
+			TCP and UDP state, including the "-s p:s"
+			option and associated speed ehancements.
+
+    HASTFS		indicates that the Pyramid dialect has TFS
+			file system support.
+
+    HAS_UFS1_2		indicates the FreeBSD 6 and higher system has
+			UFS1 and UFS2 members in its inode structure.
+
+    HAS_UM_UFS		indicates the OpenBSD version has UM_UFS[12]
+			definitions.
+
+    HASUNMINSOCK	indicates the Linux version has a user name
+			element in the socket structure; a value of
+			0 says there is no unix_address member; 1,
+			there is.
+
+    HASUINT16TYPE	is defined when the dialect has a typedef
+			for u_int16 that may conflict with some other
+			header file's redefinition (e.g., <afs/std.h>).
+
+    HASUTMPX		indicates the dialect has a <utmpx.h> header
+			file.
+
+    HAS_UVM_INCL	indicates the NetBSD or OpenBSD dialect has
+			a <uvm> include directory.
+
+    HAS_UW_CFS      	indicates the UnixWare 7.1.1 or above dialect
+			has CFS file system support.
+
+    HAS_UW_NSC		indicates the UnixWare 7.1.1 or above dialect
+			has a NonStop Cluster (NSC) kernel.
+
+    HAS_V_LOCKF		indicates the FreeBSD version has a v_lockf
+			member in the vode structure, defined in
+			<sys/vnode.h>.
+
+    HAS_VM_MEMATTR_T	indicates the FreeBSD <sys/conf.h> uses the
+			vm_memattr_t typedef.
+
+    HASVMLOCKH		indicates the FreeBSD dialect has <vm/lock.h>.
+
+    HASVNODE		enables/disables readvnode() function in node.c.
+
+    HAS_V_PATH          indicates the dialect's vnode structure has a
+			v_path member.
+
+    HAS_VSOCK		indicates that the Solaris version has a VSOCK
+			member in the vtype enum
+
+    HASVXFS		enables Veritas VxFS file system support for
+			the dialect.  CAUTION, the dialect sources
+			must have the necessary support code.
+
+    HASVXFSDNLC         indicates the VxFS file system has its own
+			name cache.
+
+    HASVXFS_FS_H	indicates <sys/fs/vx_fs.h> exists.
+
+    HASVXFS_MACHDEP_H	indicates <sys/fs/vx_machdep.h> exists.
+
+    HASVXFS_OFF64_T	indicates <sys/fs/vx_solaris.h> exists and
+			has an off64_t typedef.
+
+    HASXVFSRNL		indicates the dialect has VxFS Reverse Name
+			Lookup (RNL) support.
+
+    HASVXFS_SOL_H	indicates <sys/fs/vx_sol.h> exists.
+
+    HASVXFS_SOLARIS_H	indicates <sys/fs/vx_solaris.h> exists.
+
+    HASVXFS_U64_T       if HASVXFS_SOLARIS_H is defined, this
+			variable indicates that <sys/fs/vx_solaris.h>
+			has a vx_u64_t typedef.
+
+    HASVXFSUTIL         indicates the Solaris dialect has VxFS 3.4
+			or higher and has the utility libraries,
+			libvxfsutil.a (32 bit) and libvxfsutil64.a
+			(64 bit).
+
+    HASVXFS_VX_INODE    indicates that <sys/fs/vx_inode.h> contains
+			a vx_inode structure.
+
+    HASWCTYPE_H		indicates the FreeBSD version has wide-character
+			support and the <wctype.h> header file.  Note:
+			the HASWIDECHAR #define will also be set.
+
+    HASWIDECHAR         indicates the dialect has the wide-character
+			support functions iswprint(), mblen() and mbtowc().
+
+    HASXNAMNODE         indicates the OSR dialect has <sys/fs/xnamnode.h>.
+
+    HASXOPT		defines help text for dialect-specific X option
+			and enables X option processing in usage.c and
+			main.c.
+
+    HASXOPT_ROOT        when defined, restricts the dialect-specific
+			X option to processes whose real user ID
+			is root.
+
+    HAS_ZFS		indicates the dialect has support for the ZFS file
+			system.
+
+    HASXOPT_VALUE	defines the default binary value for the X option
+			in store.c.
+
+    HASZONES		the Solaris dialect has zones.
+
+    HAVECLONEMAJ        defines the name of the status variable
+			that indicates a clone major device number
+			is available in CLONEMAJ.  (Also see CLONEMAJ
+			and HAS_STD_CLONE.)
+
+    HPUX_KERNBITS	defines the number of bits in the HP-UX 10.30
+			and above kernel "basic" word: 32 or 64.
+
+    KA_T		defines the type cast required to assign
+			space to kernel pointers.  When not defined
+			by a dialect header file, KA_T defaults to
+			unsigned long.
+
+    KA_T_FMT_X          defines the printf format for printing a
+			KA_T -- the default is "%#lx" for the
+			default unsigned long KA_T cast.
+
+    LSOF_ARCH		See 00XCONFIG.
+
+    LSOF_BLDCMT		See 00XCONFIG.
+
+    LSOF_CC		See 00XCONFIG.
+
+    LSOF_CCV		See 00XCONFIG.
+
+    LSOF_HOST		See 00XCONFIG.
+
+    LSOF_INCLUDE	See 00XCONFIG.
+
+    LSOF_LOGNAME	See 00XCONFIG.
+
+    LSOF_MKC		See the "The Mksrc Shell Script" section of
+			this file.
+
+    LSOF_SYSINFO	See 00XCONFIG.
+
+    LSOF_USER		See 00XCONFIG.
+
+    LSOF_VERS		See 00XCONFIG.
+
+    LSOF_VSTR		See 00XCONFIG.
+
+    MACH		defines a MACH system.
+
+    N_UNIXV		defines an alternate value for the N_UNIV symbol.
+
+    NCACHELDPFX		defines C code to be executed before calling
+			ncache_load().
+
+    NCACHELDSFX		defines C code to be executed after calling
+			ncache_load().
+
+    NEEDS_BOOLEAN_T	indicates the FreeBSD 9 and above system needs a
+			boolean_t definition for <sys/conf.h>.
+
+    NEEDS_MACH_PORT_T	is defined for Darwin versions that need the inclusion
+			of the header file <device/device_types.h>.
+
+    NEVER_HASDCACHE	keeps the Customize script from offering to
+			change HASDCACHE by its presence anywhere
+			in a dialect's machine.h header file --
+			e.g., in a comment.  See the Customize
+			script or machine.h in dialects/linux/proc.
+
+    NEVER_WARNDEVACCESS	keeps the Customize script from offering to
+			change WARNDEVACCESS by its presence anywhere
+			in a dialect's machine.h header file --
+			including in a comment.  See the Customize
+			script or machine.h in dialects/linux/proc.
+
+    NLIST_TYPE		is the type of the nlist table, Nl[], if it is
+			not nlist.  HASNLIST must be set for this
+			definition to be effective.
+
+    NOWARNBLKDEV        specifies that no warning is to be issued
+			when no block devices are found.  This
+			definiton is used only when HASBLKDEV is
+			also defined.
+
+    OFFDECDIG           specifies how many decimal digits will be
+			printed for the file offset in a 0t form
+			before switching to a 0x form.  The count
+			includes the "0t".  A count of zero means
+			the size is unlimited.
+
+    PRIVFILETYPE        is the number of a private file type, found
+			in the f_type member of the file struct, to
+			be processed by the HASPRIVFILETYPE function.
+			See the AIX dialect sources for an example.
+
+    _PSTAT_STREAM_GET_XPORT
+			indicates the HP-UX PSTAT header files require
+			this symbol to be defined for proper handling of
+			stream export data.
+
+    SAVE_MP_IN_SFILE	indicates the dialect needs to have the mounts
+			structure pointer for a file system search argument
+			recorded in the dialect's sfile structure.  This
+			definition is made in the dialect's dlsof.h header
+			file within the sfile structure.
+
+    TIMEVAL_LSOF        defines the name of the timeval structure.
+			The default is timeval.  /dev/kmem-based
+			Linux lsof redefines timeval with this
+			symbol to avoid conflicts between glibc
+			and kernel definitions.
+
+    TYPELOGSECSHIFT     defines the type of the cdfs_LogSecShift
+			member of the cdfs structure for UnixWare
+			7 and higher.
+
+    UID_ARG_T           defines the cast on a User ID when passed
+			as a function argument.
+
+    USE_LIB_COMPLETEVFS
+			selects the use of the completevfs() function
+			in lsof4/lib/cvfs.c.
+
+    USE_LIB_FIND_CH_INO
+			selects the use of the find_ch_ino() inode
+			function in lsof4/lib/fino.c.
+
+			Note: HASBLKDEV selects the has_bl_ino()
+			function.
+
+    USE_LIB_IS_FILE_NAMED
+			selects the use of the is_file_named() function
+			in lsof4/lib/isfn.c.
+
+    USE_LIB_LKUPDEV	selects the use of the lkupdev() function
+			in lsof4/lib/lkud.c.
+
+			Note: HASBLKDEV selects the lkupbdev() function.
+
+    USE_LIB_PRINTDEVNAME
+			selects the use of the printdevname() function
+			in lsof4/lib/pdvn.c.
+
+			Note: HASBLKDEV selects the printbdevname()
+			function.
+
+    USE_LIB_PRINT_TCPTPI
+			selects the use of the print_tcptpi() function
+			in lsof4/lib/ptti.c.
+
+    USE_LIB_PROCESS_FILE
+			selects the use of the process_file() function
+			in lsof4/lib/prfp.c.
+
+    USE_LIB_READDEV	selects the use of the readdev() and stkdir()
+			functions in lsof4/lib/rdev.c.
+
+    USE_LIB_READMNT	selects the use of the readmnt() function
+			in lsof4/lib/rmnt.c.
+
+    USE_LIB_RNAM	selects the use of the device cache functions
+			in lsof4/lib/rnam.c.
+
+			Note: HASNCACHE must also be defined.
+
+    USE_LIB_RNCH	selects the use of the device cache functions
+			in lsof4/lib/rnch.c.
+
+			Note: HASNCACHE must also be defined.
+
+    USE_STAT            is defined for those dialects that must
+			use the stat(2) function instead of lstat(2)
+			to scan /dev -- i.e., in the readdev()
+			function.
+
+    VNODE_VFLAG		is an alternate name for the vnode structure's
+			v_flag member.
+
+    WARNDEVACCESS	enables the issuing of a warning message when
+			lsof is unable to access /dev (or /device)
+			or one of its subdirectories, or stat(2)
+			a file in them. Some dialects (e.g., HP-UX)
+			have many inaccessible subdirectories and
+			it is appropriate to inhibit the warning
+			for them with WARNDEVACCESS.  The -w option
+			will also inhibit these warnings.
+
+    WARNINGSTATE        when defined, disables the default issuing
+			of warning messages.  WARNINGSTATE is
+			undefined by default for all dialects in
+			the lsof distribution.
+
+    WIDECHARINCL        defines the header file to be included (if any)
+			when wide-character support is enabled with
+			HASWIDECHAR.
+
+    zeromem()		defines a macro to zero memory -- e.g., using
+			bzero() or memset().
+
+Any dialect's machine.h file and Configure stanza can serve as a
+template for building your own.  All machine.h files usually have
+all definitions, disabling some (with comment prefix and suffix)
+and enabling others.
+
+
+Options: Common and Special
+---------------------------
+
+All but one lsof option is common; the specific option is ``-X''.
+If a dialect does not support a common option, the related #define
+in machine.h -- e.g., HASCOPT -- should be deselected.
+
+The specific option, ``-X'', may be used by any dialect for its
+own purpose.  Right now (May 30, 1995) the ``-X'' option is binary
+(i.e., it's not allowed arguments of its own, and its value must
+be 0 or 1) but that could be changed should the need arise.  The
+option is enabled with the HASXOPT definition in machine.h; its
+default value is defined by HASXOPT_VALUE.
+
+The value of HASXOPT should be the text displayed for ``-X'' by
+the usage() function in usage.c.  HASXOPT_VALUE should be the
+default value, 0 or 1.
+
+AIX for the IBM RICS System/6000 defines the ``-X'' option to
+control readx() usage, since there is a bug in AIX kernels that
+readx() can expose for other processes.
+
+
+Defining Dialect-Specific Symbols and Global Storage
+----------------------------------------------------
+
+A dialect's dlsof.h and dstore.c files contain dialect-specific
+symbol and global storage definitions.  There are symbol definitions,
+for example, for function and data casts, and for file paths.
+Dslof.h defines lookup names the nlist() table -- X_* symbols --
+when nlist() is being used.
+
+Global storage definitions include such things as structures for
+local Virtual File System (vfs) information; mount information;
+search file information; and kernel memory file descriptors --
+e.g., Kmem for /dev/kmem, Mem for /dev/mem, Swap for /dev/drum.
+
+
+Coding Dialect-specific Functions
+---------------------------------
+
+Each supported dialect must have some basic functions that the
+common functions of the top level may call.  Some of them may be
+obtained from the library in lsof4/lib, selected and customized by
+#define's in the dialect machine.h header file.  Others may have
+to be coded specifically for the dialect.
+
+Each supported dialect usually has private functions, too.  Those
+are wholly determined by the needs of the dialect's data organization
+and access.
+
+These are some of the basic functions that each dialect must supply
+-- they're all defined in proto.h:
+
+    initialize()		function to initialize the dialect
+
+    is_file_named()		function to check if a file was named
+				by an optional file name argument
+				(lsof4/lib/isfn.c)
+
+    gather_proc_info()		function to gather process table
+				and related information and cache it
+
+    printchdevname()		function to locate and optionally
+				print the name of a character device
+				(lsof4/lib/pdvn.c)
+
+    print_tcptpistate()         function to print the TCP or TPI
+				state for a TCP or UDP socket file,
+				if the one in lib/ptti.c isn't
+				suitable (define USE_LIB_PRINT_TCPTPI
+				to activate lib/ptti.c)
+
+    process_file()		function to process an open file
+				structure (lsof4/lib/prfp.c)
+
+    process_node()		function to process a primary node
+
+    process_socket()		function to process a socket
+
+    readdev() and stkdir()	functions to read and cache device
+				information (lsof4/lib/rdev.c)
+
+    readmnt()			function to read mount table information
+				(lsof4/lib/rmnt.c)
+
+Other common functions may be needed, and might be obtained from
+lsof4/lib, depending on the needs of the dialect's node and socket
+file processing functions.
+
+Check the functions in lsof4/lib and specific lsof4/dialects/*
+files for examples.
+
+As you build these functions you will probably have to add #include's
+to dlsof.h.
+
+
+Function Prototype Definitions and the _PROTOTYPE Macro
+-------------------------------------------------------
+
+Once you've defined your dialect-specific definitions, you should
+define their prototypes in dproto.h or locally in the file where
+they occur and are used.  Do this even if your compiler is not ANSI
+compliant -- the _PROTOTYPE macro knows how to cope with that and
+will avoid creating prototypes that will confuse your compiler.
+
+
+The Makefile
+------------
+
+Here are some general rules for constructing the dialect Makefile.
+
+    *  Use an existing dialect's Makefile as a template.
+
+    *  Make sure the echo actions of the install rule are appropriate.
+
+    *  Use the DEBUG string to set debugging options, like ``-g''.
+       You may also need to use the -O option when forking and
+       SIGCHLD signals defeat your debugger.
+
+    *  Don't put ``\"'' in a compiler flags -D<symbol>=<string>
+       clause in your Makefile.  Leave off the ``\"'' even though
+       you want <string> to be a string literal and instead adapt
+       the N_UNIX* macros you'll find in Makefiles for FreeBSD
+       and Linux.  That will allow the Makefile's version.h rule
+       to put CFLAGS into version.h without having to worry about
+       the ``\"'' sequences.
+
+    *  Finally, remember that strings can be passed from the top
+       level's Configure shell script.  That's an appropriate way
+       to handle options, especially if there are multiple versions
+       of the Unix dialect to which you are porting lsof 4.
+
+
+The Mksrc Shell Script
+----------------------
+
+Pattern your Mksrc shell script after an existing one from another
+dialect.  Change the D shell variable to the name of your dialect's
+subdirectory in lsof4/dialects.  Adjust any other shell variable
+to your local conditions.  (Probably that won't be necessary.)
+
+Note that, if using symbolic links from the top level to your
+dialect subdirectory is impossible or impractical, you can set the
+LSOF_MKC shell variable in Configure to something other than
+"ln -s" -- e.g., "cp," and Configure will pass it to the Mksrc
+shell script in the M environment variable.
+
+
+The MkKernOpts Shell Script
+---------------------------
+
+The MkKernOptrs shell script is used by some dialects -- e.g.,
+Pyramid DC/OSx and Reliant UNIX -- to determine the compile-time
+options used to build the current kernel that affect kernel structure
+definitions, so those same options can be used to build lsof.
+Configure calls MkKernOpts for the selected dialects.
+
+If your kernel is built with options that affect structure definitions.
+-- most commonly affected are the proc structure from <sys/proc.h>
+and the user structure from <sys/user.h> -- check the MkKernOpts
+in lsof4/dialects/irix for a comprehensive example.
+
+
+Testing and the Lsof Test Suite
+-------------------------------
+
+Once you have managed to create a port, here are some tips for
+testing it.
+
+*  First look at the test suite in the tests/ sub-directory of the
+   lsof distribution.  While it will need to be customized to be
+   usable with a new port, it should provide ideas on things to
+   test.  Look for more information about the test suite in the
+   00TEST file.
+
+*  Pick a simple process whose open files you are likely to
+   know and see if the lsof output agrees with what you know.
+   (Hint: select the process with `lsof -p <process_PID>`.)
+
+   Are the device numbers and device names correct?
+
+   Are the file system names and mount points correct?
+
+   Are inode numbers and sizes correct?
+
+   Are command names, file descriptor numbers, UIDs, PIDs, PGIDs,
+   and PPIDs correct?
+
+   A simple tool that does a stat(2) of the files being examined
+   and reports the stat struct contents can provide a reference for
+   some values; so can `ls -l /dev/<device>`.
+
+*  Let lsof list information about all open files and ask the
+   same questions.  Look also for error messages about not being
+   able to read a node or structure.
+
+*  Pick a file that you know is open -- open it and hold it
+   that way with a C program (not vi), if you must.  Ask lsof to
+   find the file's open instance by specifying its path to lsof.
+
+*  Create a C program that opens a large number of files and holds
+   them open.  Background the test process and ask lsof to list
+   its files.
+
+*  Generate some locks -- you may need to write a C program to
+   do this, hold the locked file open, and see if lsof can identify
+   the lock properly.  You may need to write several C programs
+   if your dialect supports different lock functions -- fnctl(),
+   flock(), lockf(), locking().
+
+*  Identify a process with known Internet file usage -- inetd
+   is a good one -- and ask lsof to list its open files.  See if
+   protocols and service names are listed properly.
+
+   See if your lsof identifies Internet socket files properly for
+   rlogind or telnetd processes.
+
+*  Create a UNIX domain socket file, if your dialect allows it,
+   hold it open by backgrounding the process, and see if lsof can
+   identify the open UNIX domain socket file properly.
+
+*  Create a FIFO file and see what lsof says about it.
+
+*  Watch an open pipe -- `lsof -u <your_login>  | less` is a
+   good way to do this.
+
+*  See if lsof can identify NFS files and their devices properly.
+   Open and hold open an NFS file and see if lsof can find the open
+   instance by path.
+
+*  If your test system has CD-ROM and floppy disk devices, open
+   files on them and see if lsof reports their information correctly.
+   Such devices often have special kernel structures associated
+   with them and need special attention from lsof for their
+   identification.  Pay particular attention to the inode numbers
+   lsof reports for CD-ROM and floppy disk files -- often they are
+   calculated dynamically, rather than stored in a kernel node
+   structure.
+
+*  If your implementation can probe the kernel name cache, look
+   at some processes with open files whose paths you know to see
+   if lsof identifies any name components.  If it doesn't, make
+   sure the name components are in the name cache by accessing
+   the files yourself with ls or a similar tool.
+
+*  If your dialect supports the /proc file system, use a C program
+   to open files there, background a test process, and ask lsof to
+   report its open files.
+
+*  If your dialect supports fattach(), create a small test program
+   to use it, background a test process, and ask lsof to report
+   its open files.
+
+I can supply some quick-and-dirty tools for reporting stat buffer
+contents, holding files open, creating UNIX domain files, creating
+FIFOs, etc., if you need them.
+
+
+Where Next?
+-----------
+
+Is this document complete?  Certainly not!  One might wish that it
+were accompanied by man pages for all lsof functions, by free beer
+or chocolates, by ...  (You get the idea.)
+
+But those things are not likely to happen as long as lsof is a
+privately supported, one man operation.
+
+So, if you need more information on how lsof is constructed or
+works in order to do a port of your own, you'll have to read the
+lsof source code.  You can also ask me questions via email, but
+keep in mind the private, one-man nature of current lsof support.
+
+
+Vic Abell <abe@purdue.edu>
+January 2, 2013
diff --git a/00QUICKSTART b/00QUICKSTART
new file mode 100644
index 0000000..697734e
--- /dev/null
+++ b/00QUICKSTART
@@ -0,0 +1,1023 @@
+
+			A Quick Start for Lsof
+
+1.  Introduction
+================
+
+  Agreed, the lsof man page is dense and lsof has a plethora of
+  options.  There are examples, but the manual page format buries
+  them at the end.  How does one get started with lsof?
+
+  This file is an attempt to answer that question.  It plunges
+  immediately into examples of lsof use to solve problems that
+  involve looking at the open files of Unix processes.
+
+
+			    Contents
+
+	    1.  Introduction
+	    2.  Finding Uses of a Specific Open File
+	    3.  Finding Open Files Filling a File System
+		a.  Finding an Unlinked Open File
+	    4.  Finding Processes Blocking Umount
+	    5.  Finding Listening Sockets
+	    6.  Finding a Particular Network Connection
+	    7.  Identifying a Netstat Connection
+	    8.  Finding Files Open to a Named Command
+	    9.  Deciphering the Remote Login Trail
+		a.  The Fundamentals
+		b.  The idrlogin.perl[5] Scripts
+	    10. Watching an Ftp or Rcp Transfer
+	    11. Listing Open NFS Files
+	    12. Listing Files Open by a Specific Login
+		a.  Ignoring a Specific Login
+	    13. Listing Files Open to a Specific Process Group
+	    14. When Lsof Seems to Hang
+		a.  Kernel lstat(), readlink(), and stat() Blockages
+		b.  Problems with /dev or /devices
+		c.  Host and Service Name Lookup Hangs
+		d.  UID to Login Name Conversion Delays
+	    15. Output for Other Programs
+	    16. The Lsof Exit Code and Shell Scripts
+	    17. Strange messages in the NAME column
+
+			Options
+
+	    A.  Selection Options
+	    B.  Output Options
+	    C.  Precautionary Options
+	    D.  Miscellaneous Lsof Options
+
+
+2.  Finding Uses of a Specific Open File
+========================================
+
+  Often you're interested in knowing who is using a specific file.
+  You know the path to it and you want lsof to tell you the processes
+  that have open references to it.
+
+  Simple -- execute lsof and give it the path name of the file of
+  interest -- e.g.,
+
+  $ lsof /etc/passwd
+
+  Caveat: this only works if lsof has permission to get the status
+  (via stat(2)) of the file at the named path.  Unless the lsof
+  process has enough authority  -- e.g., it is being run with a
+  real User ID (UID) of root -- this AIX example won't work:
+
+  Further caveat: this use of lsof will fail if the stat(2) kernel
+  syscall returns different file parameters -- particularly device
+  and inode numbers -- than lsof finds in kernel node structures.
+  This condition is rare and is usually documented in the 00FAQ
+  file of the lsof distribution.
+
+  $ lsof /etc/security/passwd
+  lsof: status error on /etc/security/passwd: Permission denied
+
+
+3.  Finding Open Files Filling a File System
+============================================
+
+  Oh! Oh!  /tmp is filling and ls doesn't show that any large files
+  are being created.  Can lsof help?
+
+  Maybe.  If there's a process that is writing to a file that has
+  been unlinked, lsof may be able to discover the process for you.
+  You ask it to list all open files on the file system where /tmp
+  is located.
+
+  Sometimes /tmp is a file system by itself.  In that case,
+
+  $ lsof /tmp
+
+  is the appropriate command.  If, however, /tmp is part of another
+  file system, typically /, then you may have to ask lsof to list
+  all files open on the containing file system and locate the
+  offending file and its process by inspection -- e.g.,
+
+    $ lsof / | more
+  or
+    $ lsof / | grep ...
+
+  Caveat: there must be a file open to a for the lsof search to
+  succeed.  Sometimes the kernel may cause a file reference to
+  persist, even where there's no file open to a process.  (Can you
+  say kernel bug?  Maybe.)  In any event, lsof won't be able to
+  help in this case.
+
+  a.  Finding an Unlinked Open File
+  =================================
+
+  A pesky variant of a file that is filling a file system is an
+  unlinked file to which some process is still writing.  When a
+  process opens a file and then unlinks it, the file's resources
+  remain in use by the process, but the file's directory entries
+  are removed.  Hence, even when you know the directory where the
+  file once resided, you can't detect it with ls.
+
+  This can be an administrative problem when the unlinked file is
+  large, and the process that holds it open continues to write to
+  it.  Only when the process closes the file will its resources,
+  particularly disk space, be released.
+
+  Lsof can help you find unlinked files on local disks.  It has an
+  option, +L, that will list the link counts of open files.  That
+  helps because an unlinked file on a local disk has a zero link
+  count.  Note: this is NOT true for NFS files, accessed from a
+  remote server.
+
+  You could use the option to list all files and look for a zero
+  link count in the NLINK column -- e.g.,
+
+    $lsof +L
+    COMMAND   PID USER   FD  TYPE DEVICE SIZE/OFF NLINK  NODE NAME
+    ...
+    less    25366  abe  txt  VREG    6,0    40960     1 76319 /usr/...
+    ...
+  > less    25366  abe    3r VREG    6,0    17360     0 98768 / (/dev/sd0a)
+
+  Better yet, you can specify an upper bound to the +L option, and
+  lsof will select only files that have a link count less than the
+  upper bound.  For example:
+
+    $ lsof +L1
+    COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NLINK  NODE NAME
+    less    25366  abe    3r  VREG    6,0    17360     0 98768 / (/dev/sd0a)
+
+  You can use lsof's -a (AND) option to narrow the link count search
+  to a particular file system.  For example, to look for zero link
+  counts on the /home file system, use:
+
+    $ lsof -a +L1 /home
+
+  CAUTION: lsof can't always report link counts for all file types
+  -- e.g., it may not report them for FIFOs, pipes, or sockets.
+  Remember also that link counts for NFS files on an NFS client
+  host don't behave as do link counts for files on local disks.
+
+
+4.  Finding Processes Blocking Umount
+=====================================
+
+  When you need to unmount a file system with the umount command,
+  you may find the operation blocked by a process that has a file
+  open on the file systems.  Lsof may be able to help you find the
+  process.  In response to:
+
+  $ lsof <file_system_name>
+
+  Lsof will display all open files on the named file system.  It
+  will also set its exit code zero when it finds some open files
+  and non-zero when it doesn't, making this type of lsof call
+  useful in shell scripts.  (See section 16.)
+