Bug 9163 - ln -sf doesn't change symlink to directory
Summary: ln -sf doesn't change symlink to directory
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: fileutils (Show other bugs)
(Show other bugs)
Version: 6.1
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-02-06 19:02 UTC by Peter J. Holzer
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-02-06 19:30:53 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Peter J. Holzer 2000-02-06 19:02:05 UTC
Demonstration:

First try it with regular files:

% touch a b
% ln -s a c
% ll -d ?
-rw-r--r--   1 hjp      hjp             0 Feb  6 19:46 a
-rw-r--r--   1 hjp      hjp             0 Feb  6 19:46 b
lrwxrwxrwx   1 hjp      hjp             1 Feb  6 19:46 c -> a
% ln -sf b c
% ll -d ?
-rw-r--r--   1 hjp      hjp             0 Feb  6 19:46 a
-rw-r--r--   1 hjp      hjp             0 Feb  6 19:46 b
lrwxrwxrwx   1 hjp      hjp             1 Feb  6 19:46 c -> b

As expected, the link now points to b.

But if a and b are directories:

% rm a b
% mkdir a b
% ln -sf a c
% ll -d ?
drwxr-xr-x   2 hjp      hjp          4.0k Feb  6 19:47 a/
drwxr-xr-x   2 hjp      hjp          4.0k Feb  6 19:47 b/
lrwxrwxrwx   1 hjp      hjp             1 Feb  6 19:46 c -> b/

the link is not changed and there isn't any error message, either.

Comment 1 Peter J. Holzer 2000-02-06 19:04:59 UTC
Oops, I found the link :-)

It is created inside  of the directory:

% ll b
total 0
lrwxrwxrwx   1 hjp      hjp             1 Feb  6 19:47 a -> a

Not very useful. I still think this is a bug.

Comment 2 Bernhard Rosenkraenzer 2000-02-06 19:30:59 UTC
Actually it's not a bug.
At the time a and b are created as directories, c is still a symlink to b, so at
this point, c is a directory as well.
As expected and documented, ln -sf file directory is the same as ln -sf file
directory/file - it's the way ln works (100% the same thing cp does).


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