[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug#369822: ls -i stats unnecessarily
From: |
James Youngman |
Subject: |
Re: Bug#369822: ls -i stats unnecessarily |
Date: |
Sat, 3 Jun 2006 10:49:55 +0100 |
On 6/2/06, Ian Jackson <address@hidden> 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 of its symlink race condition paranoia
checking). It makes the program hang is the system is a client of a
dead NFS server, even if the user is not using "ls" to work with
filesystems on that server.
There were many bug reports. I ended up finding an alternative way to
solve the problem.
If I was trying to diagnose a problem on a client of a dead NFS
server, I would expect "ls" to _help_ in the diagnosis, not be
affected by the problem too. For a fundamental tool like ls, it is
reasonable to favour robusness over performance.
I suppose one could have a fast /bin/ls and a robust /sbin/ls, but
that would I think only lead to people including the wrong binary in
rescue disks (having said this though of course that special niche is
often filled by busybox anyway).
James.
- Re: Bug#369822: ls -i stats unnecessarily, Jim Meyering, 2006/06/01
- Re: Bug#369822: ls -i stats unnecessarily, Jim Meyering, 2006/06/01
- Re: Bug#369822: ls -i stats unnecessarily, James Youngman, 2006/06/01
- Re: Bug#369822: ls -i stats unnecessarily, Jim Meyering, 2006/06/02
- Re: Bug#369822: ls -i stats unnecessarily, Paul Eggert, 2006/06/03
- Re: Bug#369822: ls -i stats unnecessarily, Ian Jackson, 2006/06/05
- Re: Bug#369822: ls -i stats unnecessarily, Paul Eggert, 2006/06/05