[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [anonymous] [bugs #11124] ls stats symbolic link targets (fwd)
Re: [anonymous] [bugs #11124] ls stats symbolic link targets (fwd)
Sun, 28 Nov 2004 16:30:07 -0700
Jim Meyering wrote:
> Forwarding from savannah.
> Subject: [bugs #11124] ls stats symbolic link targets
> From: anonymous <address@hidden>
> URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=11124>
Since that bug was posted anonymously I don't see how any reasonable
discussion can make it back to the original bug poster. Sigh.
> Summary: ls stats symbolic link targets
Only if the user specifically asks for that behavior. And if the user
specifically asks for it then I don't think there is anything else
that can be done about it. The old joke says, "Doctor it hurts when I
do this." The doctor says, "Don't do that."
I do not believe this is a GNU coreutils issue. This is a system
integration issue. The 'distro' or other system integration would
deal with this as part of the configuration of the overall system.
Therefore this note from here on down is off-topic for this mailing
list. Delete now if you are not interested in this off-topic
Off topic discussion follows.
> Original Submission: ls appears to stat not only the files in the
> directory being listed, but also files that are referenced by symbolic
> links. This can take a significant amount of time if the links are to
> automounted NFS directories, for example.
That behavior has always been true when using NFS filesystems. It can
also block in that case too since you are leaving your own local host
and asking a remote host to respond. NFS has a long history of
problems and issues with regard to things like this. But so far
improved replacements have not been available to replace NFS. And so
NFS is still the most prevalent networked filesystem. I would love to
have an improved replacement widely available.
> The setup I noticed this with is two Fedora Core 2 systems
> configured with /net automounting between them and convenience
> symbolic links in the root of one machine (/mp3 -> net/other/mp3).
Ew, symlinks from / to another machine! That is strictly forbidden on
any machine I administer. I imagine that any group with a history of
using NFS has similar conventions.
[Aside: In the old days on SysV systems at least 'ps' would hang if a
/symlink would also hang. I can only guess at what existed in the
source code to create that behavior. But it is one of the reasons I
forbid /symlinks off the local machine. If you must have them then
they must exist in a subdirectory below / such as /somedir/somelink.]
> I can imagine this being intolerable on systems where /home is
> full of links to host:/export/home/user, which I believe to be
> fairly common practice.
Hmm... I don't think I would call that common practice. If anything
I think people try to avoid having a farm of symlinks specifically for
that reason. I think if anything doing it that way is a naive
implementation prone to this problem and others too. I think it is
unfair to blame 'ls' here.
There are three types of mounts for the automounter. 'host' maps,
'direct' maps and 'indirect' maps.
Personally I am most familiar with 'host' maps in /net where
/net/somehostname maps to a local machine. To me this is the most
common type of automount I see. But it is cultural and other people
will have other experiences. And there are also numerous problems
with host maps. It is what we normally do here. But I know other
shops that forbid host maps.
To avoid the problems with 'host' maps many people use 'direct' maps.
Basically generate a list of every possible mount point. Then
automounter knows about every possible directory. An 'ls -l' NFS
mounts everything. This causes "mount storms". This is the same
problem the poster is complaining about.
To solve the problem of needing a fully populated table of mount
points 'indirect' maps where wildcards are used to generate the
entries. I dare say that indirect maps are the most common type of
automount map used, usually in conjunction with an NIS/YP map. An
'ls -l' in one of those directories will not cause mount storms.
There are lots of advantages. But they are the most complicated to
configure and set up for the first time too.
> This behaviour only appears to happen when the --color=tty option is
> used, but as this is the default on Red Hat distributions (at least),
Some time ago when I was a hard core user of Red Hat systems I filed a
bug against Red Hat's setting of 'ls --color' from /etc/profile. There
was no way for a user to opt-out of it. As I recall Red Hat closed
the bug with only "Our customers prefer it that way." and no further
discussion was allowed on the topic. But setting those things
unconditionally from /etc/profile is Evil. Other distros do not do it
that way. It is a user preference and should only be allowed in a
user's profile. User preferences such as that are much better to be
put in the skeleton files so that it is set up by default, as many
users do actually prefer it that way, but not unconditionally as part
of the system.
Fortunately there are many choices of distro available. If you don't
like how a distro does something you can either change it locally,
work to change it in the distro, or choose a different system
> the behaviour would be quite common. I can't immediately see why ls needs
Is this the ten thousand lemmings can't be wrong argument? (Yes, I
know that is a Disney propagated myth. Those lemmings were pushed!)
> to stat the target of the link either, because the output of ls does not
> convey any information about the link target. ('ls -l' is different as
> it includes both the name of the link target and the type of the target,
> conveyed by coloring the text.)
I believe that ls --color will paint symlinks differently depending
upon whether they are symlinks to files or symlinks to directories.
Therefore the target of the symlink must be stat'd.
> I would not expect plain 'ls' to be wandering into remote file systems,
> so I find this behaviour surprising.
I believe that a plain 'ls' will not stat the file. Stat'ing is only
done when the user specifically requests it with -c, -i, -l, -F, or
--color and others which specifically request the stat.
> It's also not immediately obvious what's going on: why should 'ls
> /' take several seconds to respond when / is a local file system?
1. Don't make /symlinks to NFS filesystems.
2. Don't alias 'ls' to something that stats files without knowing that
it stats files. (I always use 'ls -F' and use \ls when I want to
avoid that alias.)
In any case it is not an 'ls' problem. Especially after this
discussion I would suspect that there was an alias in place that
rewrote 'ls' to be something else. :-)
This reminds me of when an associate at work created an alias for
'install-files' called 'if' to save some typing. Sounds reasonable,
right? It is not if you are also going to be sourcing environment
setting scripts and those scripts use if-then-else statements. As you
might imagine after creating that alias some things did not quite work
The whole point of aliases are that they will transparently rewrite
input. A force so powerful it can only be used for ultimate good or
ultimate evil. I am sure other people have similar stories about
people aliasing 'test' and other common shell builtins and keywords.
> I can see that the behaviour of 'ls -l' in this regard is at least
Debate would need a suggestion as to how 'ls -l' can avoid calling
stat() on the file. I don't think it is debatable until such a
suggestion is made.
Sorry for the rant...