Bug 90251 - ls -L (--dereference) does not show linked name
ls -L (--dereference) does not show linked name
Status: CLOSED UPSTREAM
Product: Red Hat Linux
Classification: Retired
Component: coreutils (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-05 19:12 EDT by G. Reno
Modified: 2007-04-18 12:53 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-05-06 13:00:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description G. Reno 2003-05-05 19:12:30 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
the -L (--dereference) switch to 'ls' does not work properly.

when I enter: 
$ ls -Ld {some link}

I should NOT see the linkname but rather the filename that the link is pointing
to.  

If I want to obtain information about the file that the link is pointing to I
should be able to do:
$ ls -Lld {some link}
and see 
drwxr-xr-x   14 root     mysql        4096 Apr 22 00:00
/usr/local/mysql-max-4.1.0-alpha-pc-linux-i686
which is where my link points.  

Instead I am seeing:
drwxr-xr-x   14 root     mysql        4096 Apr 22 00:00 /usr/local/mysql
which is showing info for the linked-file all except for its name which displays
as the name of the link. - this mixture does not appear to be correct.

thx,
Gerry Reno




Version-Release number of selected component (if applicable):
coreutils-4.5.3-19

How reproducible:
Always

Steps to Reproduce:
1. read description above
2.
3.
    

Additional info:
Comment 1 Miloslav Trmac 2003-05-06 07:57:09 EDT
IMHO it seems to be right.
-L means "show information about the file symlink points to".
The file A the symlink L points to is not a symlink, therefore
the path that is printed for L doesn't show the path of the symlink,
same as it doesn't print times for L, but for A.
Comment 2 G. Reno 2003-05-06 12:42:48 EDT
Miloslav,
  I'm not understanding your comment.  You say it seems right and yet your
argument is exactly what I'm showing as the problem.  Look at my examples. 
Using -L shows you the times for the linked-file not the symlink.  That is
correct.  But it is not showing the name of the linked-file it is still showing
the name of the symlink - I'm saying that this is not correct.  When you
dereference something you expect to have everything dereferenced not just part
of something dereferenced.

thx,
Gerry Reno
Comment 3 Tim Waugh 2003-05-06 13:00:49 EDT
Reported upstream.
Comment 4 Miloslav Trmac 2003-05-06 13:09:25 EDT
G.,
look at it this way: -L makes the symlink completely behave as if it were the
file pointed to.

ls Name
   ls: Name, what are you?
   Name: I'm a symlink, modified on jan 1, pointing to Foo

ls Foo:
   ls: Foo, what are you?
   foo: i'm a regular file, modified on feb 23.

ls -l Name
   Name (pretending to be foo): I'm a regular file, modified on feb 23.

Anyway, let upstream decide.
     Mirek
Comment 5 Tim Waugh 2003-05-09 04:28:33 EDT
Jim Meyering says that this behaviour conforms to POSIX, and is consistent with
(for example) Solaris' ls(1).

He has modified the documentation to be more clear on this issue.
Comment 6 G. Reno 2003-05-09 11:39:30 EDT
Well, it may be POSIX-conformant but it is certainly a strange way to implement
dereferencing.

Note You need to log in before you can comment on or make changes to this bug.