bug-coreutils
[Top][All Lists]
Advanced

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

Re: Bug#369822: ls -i stats unnecessarily


From: Jim Meyering
Subject: Re: Bug#369822: ls -i stats unnecessarily
Date: Fri, 02 Jun 2006 10:07:00 +0200

I wrote:
> 2006-02-25  Eric Blake  <address@hidden>
>
>       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 stat when
>       possible.
>       (gobble_file): Add inode argument.
>       (print_dir): Pass inode if available.
>       (usage): Remove inaccuracy.
>
> The problem is rare enough that I won't be losing any
> sleep over it.  But it would be good to fix it, or at least
> add a test case comparing st_ino vs. d_ino for every readable
> directory from "." up to "/".  Then (from test failure reports)
> we can hope to get an idea of how often the problem arises.

Well, chance would have it that just minutes ago I saw this
new test fail on a solaris 8 system:
[ This test is on the trunk, only, as is the no-stat-for-inode
  ls optimization. ]

  ./stat-vs-dirent: test failed: /export/home: d_ino(16768) != st_ino(2)
  ./stat-vs-dirent: This may indicate a flaw in your kernel or file system 
implementation.

I see that I wrote that test less than a month ago.  Humph.
And /export/home is indeed a mount point.

  $ df|grep 'home$'
  /dev/dsk/c0t0d0s7    1935191  949204  927932    51%    /export/home

James Youngman <address@hidden> wrote:
> You could stat "/" at startup, and if its inode number is 2 (hint that
> we're probably not chrooted), trust d_ino, and don't trust it if d_ino
> is not 2 (we're probably chrooted).   The check is only probabilistic,
> but it might help.  It shouldn't be fooled by fsirand.

Unfortunately, that heuristic wouldn't work in this case:

  $ ./stat --format=%i /
  2

So at least Solaris 8 and some glibc are affected.

Unless I find a better approach, I'll turn off this optimization
by default, and add an option to turn it back on.




reply via email to

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