Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rice!rice!sun-spots-request
From: mike_s@ebay.sun.com (Mike { Whats all this then? } Sullivan)
Newsgroups: comp.sys.sun
Subject: Re: ls -i vs. stat()
Keywords: Miscellaneous
Message-ID: <1990Sep20.204251.1758@rice.edu>
Date: 21 Sep 90 00:01:49 GMT
Sender: sun-spots-request@rice.edu
Organization: Sun-Spots
Lines: 34
Approved: Sun-Spots@rice.edu
Originator: spots@titan.rice.edu
X-Sun-Spots-Digest: Volume 9, Issue 319, message 2

In <1990Aug23.225411.10266@rice.edu> jsulliva@killington.prime.com (Jeff Sullivan) writes:

> Running a simple test:
>	$ stattest stat.c
>        i-number = 2953       stat.c
>	$ ln -s stat.c stat.link
>	$ stattest stat.*
>	i-number = 2953       stat.c
>	i-number = 2953       stat.link
>	$ ln -i stat.*
	  ^^ Of course, this is 'ls'
>	  2953 stat.c      38379 stat.link

>Is this the correct output for the 'ls -i' command?  

	Yes

>I would expect all links to have the same i-number as the original.

They do, for a hard link, but a symbolic link is actually another file.
So there are two files here, which ls is showing you, but your program is
not.

The problem is that stat() follows symbolic links, while ls does not. When
you stat("stat.link"), it actually follows the link and gives you the
information about stat.c.

If you want to be like ls, use lstat(). This doesn't follow symbolic
links, it instead gives back information about the link itself, and is
what ls uses.

Mike Sullivan                     Internet: msullivan@Ebay.Sun.COM
Sun Education                     UUCP:     ..!sun!yavin!msullivan
Software Course Developer         Compuserve: 75365,764