> 	ls -i displays the incorrect inode number on symlinks and directories
> 	which are roots of filesystems.
> 	The inum displayed by ls -i on a symlink is the same as the file
> 	to which it points, or the inum of the current directory if the symlink 
> 	doesn't point to an existing file.
>>How-To-Repeat:
>	ls -i /		# to see the mount-point dir problem.
>	cd /tmp
>	ln -s foo bar
>	ls -i		# to see the symlink dir problem.
>	touch foo
>	ls -i		# look again.

i tried ls -i /, and saw nothing wrong.  in particular, e.g.:

76 [sun-lamp] doc % ls -di /. /..
2 /./   2 /../

looks fine to me.  all the rest of the directories look fine, too.

the symlink thing is a result of the fact that under 4.4BSD, symlinks
no longer have modes and permissions of their own.  Some call this a
bug.  POSIX permits symlinks to not have modes, permissions, etc., and,
actually, to be implemented as directory entries.  A future BSD file
system might not have inodes for symlinks...

however, given that knowledge, there's nothing wrong in the example
you cite:

looking at bar before foo exists shows foo, because stat() can't find
the target of the link, and returns the symlink's information.
however, symlinks no longer report inode, etc., info, so that of the
directory is returned.

looking at bar when foo exists rightly shows you bar, because stat()
traverses through the link, and looks at the underlying file.


given the current behaviour of symlinks, there's nothing wrong.
The current behaviour of symlinks itself might be an issue, but that's
really a different issue...


chris