Re: Attempting to create a symbolic link from a file in current directory to a target directory creates broken symlink

[Robert Miesen]

OK, here are the commands that reproduce the bug:

====================BEGIN SCRIPT====================
## First, setup the directories and switch to the root of the directory tree
mkdir -p LnBugDir/Dir LnBugDir/path/to/DestDir/
cd LnBugDir

## Now create a symbolic link to 'Dir' in /path/to/DestDir/
ln -s Dir ./path/to/DestDir/Dir

## Now demonstrate that the created symbolic link is broken
file ./path/to/DestDir/Dir
## RJM: This will proudly declare that the symlink is broken and that it's
## a symlink to 'Dir', not "$(pwd)/Dir"
=====================END SCRIPT=====================

I checked the FAQ for ln and it would appear that what I'm calling a 
"bug" GNU calls a "feature." However, I looked into the manuals (both 
man and the more favored info pages) and the manual does not make clear 
that the argument provided to TARGET needs to be reachable from 
LINKNAME. For example, this is what is in the info page regarding how I 
am invoking the ln command:

* If two file names are given, `ln' creates a link to the first file
from the second.

So in the manual, it is not immediately clear to someone just 
referencing the manual that if TARGET does not exist from DIRECTORY, the 
link will remain broken until the TARGET exists in DIRECTORY. That even 
seems quite counterintuitive, since it seems more like the argument I 
passed in to ln would be relative to the cwd (Current Working 
Directory), not DIRECTORY (the cwd file I'm talking about can be found 
in /proc/runningProcess/).

Thank you for your kind and informative email. It has put into 
perspective this "bug" (or "feature" depending on your interpretation.)



Bob Proulx wrote:
> Robert Miesen wrote:
>   
> > Attempting to run a command to the effect of 'ln -s Dir /path/to/DestDir/Dir
> > creates a broken symlink to "Dir" in /path/to/DestDir/. See the attached 
> > script
> > for automated bug reproduction. Same effect also happens when using the '-t'
> > option.
> >     
>
> Thank you for you bug report.  But unfortunately no script was
> attached to your message.  Please follow up to the mailing list again
> with the commands needed to reproduce the problem.  Including your
> commands inline is best.  Something small such as this is good:
>
>   mkdir testdir
>   ln -s foo testdir/
>   ls -log testdir
>
> Also please include the version of the command that you are using.
> The --version output is the best way to provide this.
>
>   ln --version
>
>   
> >    I attempted to raise this issue with Gentoo, but I got the "RTFM" 
> > response, which I had, and did again just to appease the "helpful" 
> > person, only to get RTFM again. Hopefully somebody from the GNU world 
> > (pun intended) will be able to help me out more than the person at 
> > Gentoo did. You can find all the original information on the bug as well 
> > as a cute script to help expose the bug at 
> > http://bugs.gentoo.org/show_bug.cgi?id=206911.
> >
> >    Thanks in advance for all your help.
> > <http://bugs.gentoo.org/show_bug.cgi?id=206911>
> >     
>
> I am sorry that you had a bad experience previously.  I cannot access
> that bug report URL that you provided.  It tells me Access Denied and
> informs me that I must log in to see the bug.  Sorry.
>
> Since I don't know what problem you are having I can't guess.  But in
> case it helps there is an FAQ entry for ln that may help, depending
> upon what problem you are having with it.  Please read this entry and
> perhaps by a lucky hit it will apply to your case.
>
>   
> http://www.gnu.org/software/coreutils/faq/#ln-_002ds-did-not-link-my-files-together
>
> If you are still having a problem please write to the mailing list
> again.
>
> Hope this helps,
> Bob
>
>