Anything like getpwent() for inodes?

[Guy Harris]

> Trying not to set a sarcastic tone, let me say it is a little
> anxiety forming to find out that du() and ls() do not tell
> the truth about files that have "holes" in them.  If you are on
> a system that has a lot of files with this "feature,"

I presume by putting "feature" in quotes you mean to imply that it causes
more problems than it solves and shouldn't be there.  If so, you're wrong;
several applications use files with "holes" in them, such as those using the
"dbm" library.  Since the "dbm" library, if I remember correctly, assigns
block addresses for records based on the hashed value of the key, being able
to treat the file as a sparse array is very useful.

> the problem is that programs use stat() when they should not.

As if they had a choice?  Are you saying that "du" and "ls" should be
set-UID root (so that they can read the raw disk), should have intimate
knowledge of the file system (so they can compute the number of blocks used
by a file based on its file map), and should be willing to spend a lot of
time working on each file reading the entire file map tree?

And once you've done that, what do you do if you're using NFS and the file
in question resides on an MS-DOS or VMS file system?

Life is full of tradeoffs, and I think you will find few people who would
say that the wrong tradeoffs were made in "ls" and "du".

> It is also hard to stat a file when it is not referenced in a
> directory, even though you know its inode number.

It is hard to do *anything* with a file when it is not referenced by a
directory.  The only reason there should be such files around is if 1) the
file is an unnamed pipe or 2) a file that has been removed but is still
being "kept around" because somebody still has it open or because it is a
shared-text executable that somebody is still running (yes, there *are*
systems that permit this; there is no point in forbidding it, so Berkeley
removed the check that gives ETXTBSY if you try to remove the last link to a
shared-text file).

> The system I am typing on now has such poor utilities that it prints the
> WCHAN in non-symbolic form; a UNIX system that can't tell between a wait()
> and a ttyread() makes me given to wonder.

I hope you realize that you have just described somewhere between 90% and
95% of the UNIX systems out there.  4.3BSD makes a small attempt at
improving this, and some more can be done.  The problem can *not* be solved
in general, since a routine in the kernel can sleep on any unique
"caddr_t"-sized cookie that it wishes; you'd have to do something like
modify "sleep" to take an extra argument that indicates the reason for
sleeping.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy at sun.com (or guy at sun.arpa)