From: Cesar S. <ces...@gm...> - 2011-02-03 22:52:44
|
On 2/3/2011 5:35 AM, LRN wrote: > $ echo 123>123.file > > $ cat 123.file > 123 > > $ cd bin > > $ ln -sf ../123.file /mingw/1234.file > ln: creating symbolic link `/mingw/1234.file' to `../123.file': No such > file or directory This attempts to create the following symlink on the /mingw directory: 1234.file => ../123.file Note that symlinks are relative to the directory they reside. So, this actually points to /mingw/../123.file = /123.file. Since /123.file does not exists, this would be a dangling symlink. Because MSYS implements symlinks by copying, it does not support dangling symlinks. > $ echo 2345> 2345.file > > $ cat 2345.file > 2345 > > $ ln -sf 2345.file ../23456.file > ln: creating symbolic link `../23456.file' to `2345.file': No such file > or directory This would create a 23456.file => 2345.file symlink on the parent directory. Since there is no 2345.file in the parent directory, this would be again a dangling symlink. > That is, ln -sf fails whenever one of the paths contains ".." or ".". > Works fine with absolute paths. Not true. Let's try creating a symlink pointing to a parent directory: $ echo 4321 > 4321.file $ mkdir bar $ ln -s ../4321.file bar/321.file $ ls bar 321.file > Is that a bug or a feature? It's a feature. It was introduced while solving the bug report #1798825 "ln -s does not work with relative target path": http://sourceforge.net/tracker/index.php?func=detail&aid=1798825&group_id=2435&atid=102435 > Because without "-s" it works with relative > paths just as well as with absolute paths. Hardlinks have different semantics in terms of its arguments, more like the copy operation. > And it never really creates a > symbolic link, as we all know, just a hardlink, with or without "-s". Not true. With -s, a copy is made (deep copy if it is a directory). There is work in progress to bring native symlinks to MSYS: http://sourceforge.net/tracker/index.php?func=detail&aid=3046195&group_id=2435&atid=302435 Regards, Cesar |