[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Phillip Susi
Subject: Re: making GNU ls -i (--inode) work around the linux readdir bug
Date: Tue, 8 Jul 2008 16:29:40 -0400
User-agent: Thunderbird (Windows/20080421)

Jim Meyering wrote:
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.

Going against the standard behavior is not strictly anathema, true, but you had better have a good reason for it. This 'fix' gains NOTHING since any application ( whether it exists now or conceivably could in the future ) that depends on your preferred behavior is already inherently broken. With nothing to gain, and both conformance and performance to loose, this fix seems to be bad form.

Furthermore it _is_ right even in absolute terms.

Then we'll have to agree to disagree.

So far your well-considered disagreement with the standard seems to consist solely of "it is confusing that the two inum's don't match". That seems a fairly weak argument for technical correctness. While I agree that your way makes more sense, that alone does not outweigh both performance and conformance. There are plenty of things that don't seem to make sense at first glance, but we still do them with good reason.

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)

I would argue that it is not inaccurate, since as far as correct operation of the machine is concerned, it has no effect. The perceived inaccuracy is only in your own mind while you incorrectly attempt to assign meaning to the value which has none. To justify the cost of conformance and performance, something a bit more substantial than making a human feel better needs to be achieved.

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.

You seem to have this backwards. Ian's definition of correct presupposes that the inums are useless in the presence of mount points in the first place, which they are without a dnum. It is your definition of correct that is founded solely on what you feel the behavior should be, which by all logical measures, is broken.

You have no logical reason for arguing that your way is "correct" other than that you find the other way unsettling.

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'd bet money that Linux won't since there zero reason to do so, and several reasons not to.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]