I've tried this on 2 different systems, and on both systems ln -s fails in the same way.
Here's the steps
mkdir Test cd Test
afile
cd .. ln -s Test/afile Test/afile2 ls -l Test
This is the output: /bin/ls: cannot access Test/afile2: No such file or directory total 0 -rw-rw-r--. 1 pgaltieri pgaltieri 0 Aug 24 13:46 afile l?????????? ? ? ? ? ? afile2
cd Test ln -s afile afile3 ls -l
This is the output: total 0 -rw-rw-r--. 1 pgaltieri pgaltieri 0 Aug 24 13:46 afile l?????????? ? ? ? ? ? afile2 -rw-rw-r--. 1 pgaltieri pgaltieri 0 Aug 24 13:46 afile3
ln -s Test/afile afile4 ls -l afile4
This is the output: -rw-rw-r--. 1 pgaltieri pgaltieri 0 Aug 24 13:46 afile4
The problem occurs only if the destination is in a directory.
This issue came up when trying to setup radiusd. The README.rst says
$ cd raddb $ ln -s mods-available/foo mods-enabled/foo
When I tried this as root I got the strange ln behaviour, but the problem is not user specific. Anyone else seeing this? Is this a bug?
Any help is appreciated.
Paolo
On 24Aug2015 13:55, Paolo Galtieri pgaltieri@gmail.com wrote:
I've tried this on 2 different systems, and on both systems ln -s fails in the same way.
Here's the steps
mkdir Test cd Test
afile
cd .. ln -s Test/afile Test/afile2 ls -l Test
This is the output: /bin/ls: cannot access Test/afile2: No such file or directory total 0 -rw-rw-r--. 1 pgaltieri pgaltieri 0 Aug 24 13:46 afile l?????????? ? ? ? ? ? afile2
[...]
Firstly, run "/bin/ls", not "ls". Many system ship with an alias called "ls" with presupplied various options, which is misleading. IMO this is a terrible idea - the alias should at least use another name. (I have ones called "l" and "L" for these conveniences, myself.)
To your problem:
Symlinks are strings resolved with respect to the directory in which the symlink exists.
So the example above "Test/afile" => "Test/afile2" makes a symlink _in_ the directory "Test" named "afile2" pointing at "Test/afile". Therefore it tries to access the path "Test/Test/afile", which fails as one might expect.
When making a symbolic link it needs to either be (a) an absolute path or (b) relative WRT to the directory hodling the link. For the latter, the reliable way is to cd to the directory and make in from inside. That way command line filename completion prodcues working results.
Cheers, Cameron Simpson cs@zip.com.au
Unix is user-friendly. It's just picky about who its friends are.
On 08/24/2015 02:19 PM, Cameron Simpson wrote:
On 24Aug2015 13:55, Paolo Galtieri pgaltieri@gmail.com wrote:
I've tried this on 2 different systems, and on both systems ln -s fails in the same way.
Here's the steps
mkdir Test cd Test
afile
cd .. ln -s Test/afile Test/afile2 ls -l Test
This is the output: /bin/ls: cannot access Test/afile2: No such file or directory total 0 -rw-rw-r--. 1 pgaltieri pgaltieri 0 Aug 24 13:46 afile l?????????? ? ? ? ? ? afile2
[...]
Firstly, run "/bin/ls", not "ls". Many system ship with an alias called "ls" with presupplied various options, which is misleading. IMO this is a terrible idea - the alias should at least use another name. (I have ones called "l" and "L" for these conveniences, myself.)
To your problem:
Symlinks are strings resolved with respect to the directory in which the symlink exists.
So the example above "Test/afile" => "Test/afile2" makes a symlink _in_ the directory "Test" named "afile2" pointing at "Test/afile". Therefore it tries to access the path "Test/Test/afile", which fails as one might expect.
When making a symbolic link it needs to either be (a) an absolute path or (b) relative WRT to the directory hodling the link. For the latter, the reliable way is to cd to the directory and make in from inside. That way command line filename completion prodcues working results.
Cheers, Cameron Simpson cs@zip.com.au
Unix is user-friendly. It's just picky about who its friends are.
Cameron, thank you for your reply. As it turns out the ln command
ln -s Test/afile Test/afile1
does create the link. The problem as you noted is the ls command. If I do
/bin/ls -l Test
I get
total 0 -rw-rw-r--. 1 pgaltieri pgaltieri 0 Aug 25 08:20 afile lrwxrwxrwx. 1 pgaltieri pgaltieri 10 Aug 25 08:20 afile2 -> Test/afile
But doing
ls -l Test
I get
/bin/ls: cannot access Test/afile2: No such file or directory total 0 -rw-rw-r--. 1 pgaltieri pgaltieri 0 Aug 25 08:20 afile l?????????? ? ? ? ? ? afile2
I'll probably file a bug against freeradius indicating the documentation is wrong :-)
The correct way to do the link is
mkdir Test2 cd Test2 ln -s ../Test/file file cd ..
/bin/ls -l Test2 total 0 lrwxrwxrwx. 1 pgaltieri pgaltieri 10 Aug 25 08:29 afile -> Test/afile lrwxrwxrwx. 1 pgaltieri pgaltieri 13 Aug 25 08:29 afile2 -> ../Test/afile
ls -l Test2 total 0 -rw-rw-r--. 1 pgaltieri pgaltieri 0 Aug 25 08:20 afile
which is what I expect to see. The ls command is an alias of /bin/ls -LCFb.
Again thank you for your help.
Paolo
On Tue, Aug 25, 2015 at 08:34:23AM -0700, Paolo Galtieri wrote:
The correct way to do the link is
mkdir Test2 cd Test2 ln -s ../Test/file file
$ ln -s afile2 afile
Shouldn't this suffice? After all they are in the same directory. With your solution, the link will break if the directory is renamed.
cd ..
/bin/ls -l Test2 total 0 lrwxrwxrwx. 1 pgaltieri pgaltieri 10 Aug 25 08:29 afile -> Test/afile lrwxrwxrwx. 1 pgaltieri pgaltieri 13 Aug 25 08:29 afile2 -> ../Test/afile
2015-08-24 22:55 GMT+02:00, Paolo Galtieri pgaltieri@gmail.com:
I've tried this on 2 different systems, and on both systems ln -s fails in the same way.
Here's the steps
mkdir Test cd Test
afile
cd .. ln -s Test/afile Test/afile2 ls -l Test
This is the output: /bin/ls: cannot access Test/afile2: No such file or directory total 0 -rw-rw-r--. 1 pgaltieri pgaltieri 0 Aug 24 13:46 afile l?????????? ? ? ? ? ? afile2
I'm not sure, but maybe this is what -r is for:
$ mkdir Test $ > Test/afile $ ln -sr Test/afile Test/afile2 $ ls -l Test/ total 0 -rw-rw-r--. 1 simon simon 0 Aug 25 20:49 afile lrwxrwxrwx. 1 simon simon 5 Aug 25 20:49 afile2 -> afile
Andras
On 25Aug2015 08:34, Paolo Galtieri pgaltieri@gmail.com wrote:
On 08/24/2015 02:19 PM, Cameron Simpson wrote:
On 24Aug2015 13:55, Paolo Galtieri pgaltieri@gmail.com wrote: Symlinks are strings resolved with respect to the directory in which the symlink exists.
So the example above "Test/afile" => "Test/afile2" makes a symlink _in_ the directory "Test" named "afile2" pointing at "Test/afile". Therefore it tries to access the path "Test/Test/afile", which fails as one might expect.
When making a symbolic link it needs to either be (a) an absolute path or (b) relative WRT to the directory hodling the link. For the latter, the reliable way is to cd to the directory and make in from inside. That way command line filename completion prodcues working results.
[...]
thank you for your reply. As it turns out the ln command
ln -s Test/afile Test/afile1
does create the link.
Of course it does. It is just a string. You can put pretty much anything you like in there.
The problem as you noted is the ls command.
No, the problem is that the string in the symlink is _wrong_. "ls" is behaving correctly. What you have put in the symlink is wrong, because it does not correctly point at the target file.
You can either manually construct a correct symlink (suggestions above) or if you have GNU ln (true on Fedora) use the -r option to have it figure this out for you.
Cheers, Cameron Simpson cs@zip.com.au
-
Andras Simon -
Cameron Simpson -
Joe Zeff -
Paolo Galtieri -
Suvayu Ali