bugGNU Core Utilities - Bugs: bug #11124, ls stats symbolic link targets

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #11124: ls stats symbolic link targets

Submitter:  None
Submitted:  Thu 25 Nov 2004 10:07:40 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Closed

Thu 22 Sep 2005 02:50:22 PM UTC, comment #2: 

Discussion on the mailing list decided this was not a bug in GNU coreutils bug instead a system configuration convention controlled by the distro or local admin.  Nothing to change in ls so I am closing the bug.

Bob Proulx <rwp>
Group administrator
Mon 29 Nov 2004 12:40:26 AM UTC, comment #1: 

This was forwarded to the bug-coreutils mailing list for discussion.  See the archive here.

http://lists.gnu.org/archive/html/bug-coreutils/2004-11/msg00163.html

Bob Proulx <rwp>
Group administrator
Thu 25 Nov 2004 10:07:40 AM UTC, 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.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follows 1 latest change.

Date Changed by Updated Field Previous Value => Replaced by
2005-09-22 rwp Open/ClosedOpen Closed

Back to the top

Powered by Savane 3.13-758e.
Corresponding source code