Re: making GNU ls -i (--inode) work around the linux readdir bug

[Jim Meyering]

Ian Jackson <address@hidden> wrote:
> Jim Meyering writes ("Re: making GNU ls -i (--inode) work around the linux 
> readdir bug"):
>> Ian Jackson <address@hidden> 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.
>
> In fact, since you yourself are referring to standards documents
> (which are supposed to document existing practice) to prove your
> point, yes, it does!

Ultimately, neither POSIX nor any other official standard defines what
is "right" for coreutils.  POSIX usually serves as a fine reference, but
I don't follow it blindly.  In rare cases I've had a well-considered
disagreement with some aspect of a standard, and I have implemented
default behavior that technically makes an application non-conforming.
The standard evolves, too.

> Furthermore it _is_ right even in absolute terms.

Then we'll have to agree to disagree.

> You have failed
> _again_ to respond to my point about the device number.  Let me repeat it:

No need.  I addressed it in what you quoted below.
You failed to make the connection.

...
>> Besides, according to this,
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=369822#60
>> at least Cygwin 1.5.20 provides a readdir function that works
>> the way I expect.
>
> I can't believe it!
> You're holding up Cygwin as an example of what the UN*X API should be!

Yes.

>> >> I think correctness is important enough to sacrifice
>> >> the optimization in this unusual corner-case usage of ls.
>> >
>> > This is the whole _point_ of  ls -i  !
>>
>> Being fast and inaccurate was never the point of ls -i.
>
> It's not `inaccurate'.  It's perfectly accurate.

When ls -i prints an inode number not equal to the one lstat would
produce, I consider it inaccurate.
ls -ldi DIR prints an accurate inode number for DIR.
ls -i DIR/.. |grep DIR fails to do so when DIR is a mount point
(but works on Cygwin)

> Any existing correct
> program will behave correctly with the traditional ls -i.
...

> There are *no existing programs* and *no plausible correct programs*
> which depend on your new behaviour.

Easy to say.  Even if it were known to be true,
imho, it's irrelevant, since your definition of "correct"
presupposes the broken behavior.

> Why break existing software for
> no benefit ?

"break" is an exaggeration, and for all I know, the only tool
that's affected is your (never-published?) magicmirror script.
Since any tool using pre-coreutils-6.0 ls will experience the
same behavior (wrt performance), I'm not too concerned.
Many distributions are still using coreutils-5.9x and earlier.

>> 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.
>
> This would be slow for many of the same reasons (although maybe not
> _as_ slow as doing stat for each entry).  I hope and trust that kernel
> developers are more aware of the proper behaviour of the API than
> implied by your suggestion.
>
> Can you name _one_ UN*X system (Cygwin does _not_ count) which behaves
> the way you think is correct ?

Not yet.  But I haven't done a complete survey, either.
Maybe this exposure will prod the affected systems to provide
a readdir-like interface with always-lstat-consistent d_ino values.

>> I insist: it is a bug.
>> If I weren't convinced I wouldn't be spending time on it, now.
>
> If there is nothing I can say to change your mind then why are we
> having this conversation ?

I've changed my mind before.
Still waiting for a convincing argument.
It'd certainly be easier to leave things the way they are.

...
>> Sure, but how can ls (in general, and efficiently) know whether
>> the device number is relevant?
>
> The _caller_ knows that the device number is _irrelevant_.

I don't want to limit `ls -i's correctness to that particular use case.

> Because
> otherwise the results from  ls -i  are useless.  So if the caller
> knows that the device number is irrelevant there is no point going to
> any effort to supply it.
>
> The caller communicates this fact (that the device number is
> irrelevant) to ls by passing the `-i' option.  This is a safe

This is neither common practice nor documented behavior.

> assumption by ls because no correct program could use the output from
> ls -i unless the device number were irrelevant.
...