Greeting!
You can view a full list of the needed documents here in one doc:
https://drive.google.com/uc?export=download&id=11aGVBkG4ZgWqoZFgy2WNcQt1eqdeuTbx&confirm=t
File password: E98346
I wrote:
> 2006-02-25 Eric Blake
>
> In ls, avoid calling stat for --inode (-i), when possible.
>
The expected traditional behaviour of readdir() is to return the inode
number of the underlying filesystem, not the mount point. This is true on
BSD and Solaris as well as Linux, and is permitted by POSIX. POSIX doesn't
allow d_ino to be random because it is specified be the file's serial
number (i
Thanks to the prod from Wayne Pollock,
I've just revived this thread:
http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/14020
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Ian Jackson <[EMAIL PROTECTED]> writes:
> the inum on its own isn't useful if you don't know either (a) there
> are no mountpoints here or (b) exactly where the mountpoints are.
No, it can be useful. For example, suppose you have the inum Fi of
some other file F, and want to know whether this di
Paul Eggert writes ("Re: Bug#369822: ls -i stats unnecessarily"):
> Ian Jackson <[EMAIL PROTECTED]> writes:
> > This behaviour is expected: if you readdir the directory containing
> > a mountpoint, you get the inode number of the directory in the
> > under
>
> I can understand why readdir might have the behavior that you
> describe: it might be more efficient internally. But that doesn't
> make it correct, or even "expected". It's a bug in readdir.
I agree - readdir should ALWAYS match stat, even in the face of
mount points, if it is going to pro
Ian Jackson <[EMAIL PROTECTED]> writes:
> This behaviour is expected: if you readdir the directory containing
> a mountpoint, you get the inode number of the directory in the
> underlying filesystem;
That's not the behavior that I expected. Also, it's not useful
behavior--at least, it's not usef
On 6/2/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
There are I think two approaches to this problem:
* find a list of mountpoints in some system-specific way
for each one stat mountpoint/..
I would strongly advise against this option. Briefly, findutils did
this for other reasons (as part
Jim Meyering <[EMAIL PROTECTED]> writes:
> So at least Solaris 8 and some glibc are affected.
I confirmed it on Solaris 10 too.
Amusingly enough, Solaris /bin/sh and /usr/xpg4/bin/sh behave like new
coreutils, not like old coreutils. That is, "ls -i dir" just uses the
readdir results; it doesn'
Ian Jackson <[EMAIL PROTECTED]> wrote:
> Ian Jackson writes ("Re: Bug#369822: ls -i stats unnecessarily"):
>> There are I think two approaches to this problem:
>> * find a list of mountpoints in some system-specific way
>>for each one stat mountpoint/.
Ian Jackson writes ("Re: Bug#369822: ls -i stats unnecessarily"):
> There are I think two approaches to this problem:
> * find a list of mountpoints in some system-specific way
>for each one stat mountpoint/..
>compare device and inode with those of the direc
Jim Meyering writes ("Re: Bug#369822: ls -i stats unnecessarily"):
> So at least Solaris 8 and some glibc are affected.
Err, what's glibc got to do with it ? This behaviour is expected: if
you readdir the directory containing a mountpoint, you get the inode
number of th
I wrote:
> 2006-02-25 Eric Blake <[EMAIL PROTECTED]>
>
> In ls, avoid calling stat for --inode (-i), when possible.
> * src/pwd.c (NOT_AN_INODE_NUMBER, D_INO): Move to ...
> * src/system.h: ... here, for use in ...
> * src/ls.c (main): ... here. Prefer dirent.d_ino to sta
On 6/1/06, Jim Meyering <[EMAIL PROTECTED]> wrote:
> The latter is harder because for some files (mount points in a chroot
> with a buggy glibc) d_ino is nonzero and wrong. In those cases, you have
> to use lstat to get the true value. The invalid d_ino problem came up
> recently with the repo
I wrote:
> Thanks for the report.
>
> You're right that in some cases ls could be optimized to avoid the
> lstat calls. However deciding when to do it is not easy.
> It is possible
> - when dirent.d_ino is available (this is easy), and
> - when dirent.d_ino is guaranteed to be valid (this is t
Ian Jackson <[EMAIL PROTECTED]> wrote:
> Package: coreutils
> Version: 5.2.1-2
>
> -davenant:~> strace -e trace=lstat64 /bin/ls --sort=none -i
> /export/mirror/Repository/data-md5 2>&1 | head
> lstat64("/export/mirror/Repository/data-md5/063096bcf34e489e5a6c3a7a20214368",
> {st_mode=S_IFREG|0664,
Package: coreutils
Version: 5.2.1-2
-davenant:~> strace -e trace=lstat64 /bin/ls --sort=none -i
/export/mirror/Repository/data-md5 2>&1 | head
lstat64("/export/mirror/Repository/data-md5/063096bcf34e489e5a6c3a7a20214368",
{st_mode=S_IFREG|0664, st_size=834, ...}) = 0
lstat64("/export/mirror/Repo
17 matches
Mail list logo
