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
re
-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()
>
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 re
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 mea
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 a
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 it
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.
_
> > 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
http://lists.gnu.org
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.
__
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 syst
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 w
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,
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 o
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 quot
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:
> 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
>> disagreemen
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 implemen
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 o
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
>>
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
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 t
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 (of
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 inac
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 d
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 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 wee
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
>
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
>&g
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/
29 matches
Mail list logo
