[anonymous] [bugs #11124] ls stats symbolic link targets (fwd)

[Jim Meyering]

Forwarding from savannah.
-------------

  Subject: [bugs #11124] ls stats symbolic link targets
  From: anonymous <address@hidden>
  /**************************************************************************/
  [bugs #11124] Full Item Snapshot:

  URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=11124>
  Project: GNU Core Utilities
  Submitted by: 0
  On: Thu 11/25/2004 at 05:07

  Category:  None
  Severity:  5 - Average
  Item Group:  None
  Resolution:  None
  Privacy:  Public
  Assigned to:  None
  Status:  Open


  Summary:  ls stats symbolic link targets

  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. 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). 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.

  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),
  the behaviour would be quite common. I can't immediately see why ls needs
  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 would not expect plain 'ls' to be wandering into remote file systems,
  so I find this behaviour surprising. It's also not immediately obvious
  what's going on: why should 'ls /' take several seconds to respond when /
  is a local file system?

  I can see that the behaviour of 'ls -l' in this regard is at least
  debatable.