On Mon, 7 Jul 2008, Jim Meyering wrote: > Ian Jackson <[EMAIL PROTECTED]> wrote: > > > > That is all systems. All UN*X systems since the dawn of time have > > behaved this way. > > Just because everyone does it doesn't make it right.
Er, are you programming for Unix or not? > Being fast and inaccurate was never the point of ls -i. > Besides, ls had the "-i" option long before d_ino was invented. I've had a look at the 6th and 7th Edition sources, and 4.2BSD, and they all overwrite the stat st_ino value with the d_ino value (though d_ino is spelled differently in the 6th edition). It seems the Unix Way is for `ls -i` to be the command line user interface to the raw directory contents. > Or better still, maybe someone will fix Linux's getdents (the syscall > behind readdir) to do the right thing even in the presence of mount > points. I wonder if that would cause portability problems. > The old POSIX spec permitted anything. > The soon-to-be-current version of POSIX has new wording: > > The value of the structure's d_ino member shall be set to the file > serial number of the file named by the d_name member. > > Since "file serial number" is defined, and later associated with > stat.st_ino, that might be enough to cause trouble. However, I doubt > the austin group realized the implications when they wrote that. The current POSIX spec already requires that the d_ino member is the file serial number. See http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html In order to settle the current argument POSIX needs to discuss the behaviour at mount points so the wording you highlight isn't enough. Also, readdir(3) is not the only part of POSIX that needs clarifying. At the moment the POSIX spec for ls(1) says that the printed inode number is obtained using stat(2), which produces the wrong result for symbolic links as well as disagreeing with the traditional behaviour at mount points. Tony. -- f.anthony.n.finch <[EMAIL PROTECTED]> http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: SOUTHWEST VEERING WEST 5 TO 7, INCREASING GALE 8 AT TIMES. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
