Ian Jackson <[EMAIL PROTECTED]> wrote:
> Jim Meyering writes ("Re: making GNU ls -i (--inode) work around the linux
> readdir bug"):
>> 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.
>
> 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.
...
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
