Micah Cowan wrote:
He means that there _is_ no optimization. When you're applying ls -i
directly to files (ls -i non-directory, the scenario he mentioned as
not being affected), there is no readdir, there are no directory
entries, and so there is no optimization to be made. A call to stat is
Jim Meyering wrote:
When I say not affected I mean it.
Turning off the readdir optimization affects ls -i only
when it reads directory entries.
You mean you are only disabling the optimization and calling stat()
anyway for directory entries, and not normal files? Then the effect is
only
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Phillip Susi wrote:
Jim Meyering wrote:
When I say not affected I mean it.
Turning off the readdir optimization affects ls -i only
when it reads directory entries.
You mean you are only disabling the optimization and calling stat()
anyway for
Phillip Susi [EMAIL PROTECTED] wrote:
Jim Meyering wrote:
From what I've read, POSIX does not specify this.
If you know of wording that is more precise, please post a quote.
That was my point the standard does not specify that this behavior
is an error, and since every unix system since
Jim Meyering writes (Re: making GNU ls -i (--inode) work around the linux
readdir bug):
Phillip Susi [EMAIL PROTECTED] wrote:
EVERY application that invokes ls -i is effected.
Please name one.
magicmirror
Ian.
___
Bug-coreutils mailing list
EVERY application that invokes ls -i is effected.
Please name one.
magicmirror
Which nobody uses. Try again; and this time a program that is in
common use.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
Jim Meyering wrote:
EVERY application that invokes ls -i is effected.
Please name one.
I'm not sure why this isn't getting through to you. ANY and EVERY
invoker of ls -i that does or possibly could exist is effected by a
degradation of its performance.
Phillip Susi [EMAIL PROTECTED] wrote:
Jim Meyering wrote:
EVERY application that invokes ls -i is effected.
Please name one.
I'm not sure why this isn't getting through to you. ANY and EVERY
invoker of ls -i that does or possibly could exist is effected by a
degradation of its
Jim Meyering wrote:
Here are two reasons:
- lack of convincing arguments: any program that runs
ls -i non-directory ... is not affected at all.
Of course it is effected -- it takes much longer to run.
- lack of evidence that users would be adversely affected:
the only program
Phillip Susi [EMAIL PROTECTED] wrote:
Jim Meyering wrote:
Here are two reasons:
- lack of convincing arguments: any program that runs
ls -i non-directory ... is not affected at all.
Of course it is effected -- it takes much longer to run.
When I say not affected I mean it.
Turning
Jim Meyering wrote:
From what I've read, POSIX does not specify this.
If you know of wording that is more precise, please post a quote.
That was my point the standard does not specify that this behavior
is an error, and since every unix system since the dawn of time has
behaved this way,
Wayne Pollock wrote:
How can either ls or readdir be considered correct when
the output is so inconsistent? What behavior do you expect from
backup scripts (and similar tools) that use find (or readdir)?
It seems clear to me that returning the underlying inode numbers
must result in having the
Paul Eggert writes (Re: making GNU ls -i (--inode) work around the linux
readdir bug):
Tony Finch [EMAIL PROTECTED] writes:
Also, readdir(3) is not the only part of POSIX that needs clarifying.
I participated in the discussion that resulted in this new d_ino
wording being added to POSIX
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
Ian Jackson [EMAIL PROTECTED] writes:
_Why_ is it considered a bug ? Is it just that the members of the
relevant committee didn't understand what d_ino was for
I don't think that is likely; the folks involved in that discussion
list are cognizant of the issues.
Were there any examples of
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
Phillip Susi [EMAIL PROTECTED] wrote:
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
Jim Meyering wrote:
The change I expect to implement does not going against POSIX.
On the contrary, the standard actually says the current readdir
behavior is buggy. See my previous reference to a quote from
readdir's rationale.
Going against the standard behavior means differing in behavior
Phillip Susi [EMAIL PROTECTED] wrote:
The new POSIX standard verbiage you
pointed out only _hints_ that that it is incorrect behavior, with no
justification for that position.
From what I've read, POSIX does not specify this.
If you know of wording that is more precise, please post a quote.
Jim Meyering wrote:
Phillip Susi [EMAIL PROTECTED] wrote:
The new POSIX standard verbiage you
pointed out only _hints_ that that it is incorrect behavior, with no
justification for that position.
I know ls didn't use to work this (buggy!) way on old versions of
Linux. I don't think it did on
With a Linux-based kernel, GNU ls -i can list the wrong inode
for a mount point.
Ian Jackson raised this issue two years ago with
http://bugs.debian.org/369822, and Wayne Pollock reported it
last week via http://bugzilla.redhat.com/453709
FYI, now, I'm planning to make GNU ls work around what
Ian Jackson [EMAIL PROTECTED] wrote:
Jim Meyering writes (making GNU ls -i (--inode) work around the linux
readdir bug):
With a Linux-based kernel, GNU ls -i can list the wrong inode
for a mount point.
Ian Jackson raised this issue two years ago with
http://bugs.debian.org/369822
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 to say you are proposing to fix my complaint by entrenching
the thing I was complaining about.
Yes, but only
Jim Meyering [EMAIL PROTECTED] wrote:
Ian Jackson [EMAIL PROTECTED] wrote:
It's the permitted by the specs
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
Jim Meyering writes (making GNU ls -i (--inode) work around the linux readdir
bug):
With a Linux-based kernel, GNU ls -i can list the wrong inode
for a mount point.
Ian Jackson raised this issue two years ago with
http://bugs.debian.org/369822, and Wayne Pollock reported it
last week via
Jim Meyering writes (Re: making GNU ls -i (--inode) work around the linux
readdir bug):
Ian Jackson [EMAIL PROTECTED] wrote:
That is to say you are proposing to fix my complaint by entrenching
the thing I was complaining about.
Yes, but only on a system where readdir- and lstat-reported
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
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
On Mon, 7 Jul 2008, Ian Jackson wrote:
When files are only in a single filesystem the inum is sufficient to
uniquely identify a file. But when we consider more than one
filesystem, the inum and device are needed together because inums on
different filesystems are unrelated and may be (often
Tony Finch [EMAIL PROTECTED] writes:
Also, readdir(3) is not the only part of POSIX that needs clarifying.
I participated in the discussion that resulted in this new d_ino
wording being added to POSIX, and my recollection is that the common
behavior where readdir returns the inode number of the
30 matches
Mail list logo
