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

[Bob Proulx]

Robert Miesen wrote:
> I checked the FAQ for ln and it would appear that what I'm calling a 
> "bug" GNU calls a "feature."

GNU is implementing previously existing behavior.  Symbolic links
originated in BSD.  It is a BSD feature that migrated to System V and
then to GNU and elsewhere.  The behavior is now standardized by POSIX
so that it will always be the same everywhere and it is possible to
write portable scripts that behavior the same everywhere.

> 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.

As an aside let me note that suggestions for improvements to the
documentation are always appreciated.

> 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.

Hmm...  That refers to the default 'ln' behavior *without* the -s
option.  Before the -s option appeared in the tool that statement was
true.  But with the addition of the -s option that statement is not
always true.  It doesn't apply when the -s option is given because
that changes the behavior from being a hard link to a symbolink link.
Instead of actually placing another link to the file in the directory
it places a special file that stores that value given in it.  Usually
the value given is used to point to a file but it is a generic symbol
and may be anything.

> 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.

Trying to document all of the existing behavior has always been hard
and problematic to get right.

> 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/).

Again, this is the way it was originally implemented a couple of
decades ago in BSD.  The 'ln -s' doesn't actually link two files
together but instead creates a special file with the string value
given.  The filesystem will redirect through the value of the symbolic
link for most filesystem operations.  The symlink doesn't need to
point to an existing file.  It is a name resolution which happens at
runtime.  It might resolve to different files at different times.

Normally it is a path to another file.  But you can give it anything
you want there.  You can store the name of your dog there if you wish
or use it to store a very small shopping list.  It is more flexible
and more useful the way that it is implemented.  It is often used for
lock files storing the name of the locker for example.  But that
flexibility means that you depending upon what you want to do with it
that you might or might not do what you wanted to do.

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

Most importantly not having it work this way would break a lot of
legacy code that expects it to work the way that it does.  Symlinks
have been "an addition" to the operating model since the feature was
introduced in BSD and because it was an addition has never been
seamlessly integrated.  And it can't now because the filesystem model
with the symlink addition has seen such wide use that any changes
would be very disruptive.

Bob