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

Submitted by:  None
Submitted on:  Thu 25 Nov 2004 10:07:40 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: None
Privacy: PublicAssigned 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>
Project 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>
Project 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

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follows 1 latest change.

Date Changed By Updated Field Previous Value => Replaced By
Thu 22 Sep 2005 02:50:22 PM UTCrwpOpen/ClosedOpen=>Closed

Back to the top


Powered by Savane 3.1-cleanup1