Symlinks are bad. They break the natural semantics of a hierarchical tree-like filesystem, and turn it into a messy half-assed graph.
What happens if you move a symlink? Will it still point to the same object? That depends on whether it's relative or absolute. What if you move the directory containing it? Do you have to recursively check for the correctness of links every time you operate on a directory? Sounds unreasonable to me... What if it links to a location which isn't mounted? Whats the definition of '..'? If you cd into a linked directory and do an 'ls ..', should that list the parent of the target or the link? How would you implement that?
The point is, symlinks are a messy kluge which probably wasn't thought out very well. You can look at what Rob Pike has to say about it himself on http://cm.bell-labs.com/sys/doc/lexnames.html
You have file at /some/path, then you put newer version of that file to /some/path, replacing the old file, and the symlink still points at the same address, and it doesn't matter what actually happened with the file itself.
It's useful enough to warrant its own abstraction.
I can understand why he wouldn't like symlinks. They weren't introduced until 4.2BSD and they seem like a bit of a hack. Compare them to hard links. If you move the destination file the hard link remains, but the symlink is broken and there's no simple way to figure out where the destination file was mved to. Also hard links include reference counting so you know that someone is pointing to your file. Not so with symlinks. Also, hard links mirror the permissions of symlinks.
Note that the history shows up in the ln command which originally only created hard links, and then got the -s parameter when symlinks were introduced.
Could be worse. Could be Windows desktop shortcuts. Fuzzy logic of target resolution? Now that's messy.
Symlinks may be ugly and/or dangerous relative to the original file system concept, but they solve problems. They are not "all good", but life would be worse without them. E.g. - application by application implementation of location aliases a la IIS virual directories (or whatever they called it) for web applications.
I tried using hard links back in the late nineties when I was new to linux. Instead of creating a second link to the file it copied the file to the new directory. I discovered the problem when I modified one copy and found the second copy, which was supposed to be a hard link, wasn't changed. I don't know what went wrong, but with symlinks available, I just never bothered trying hard links again.
ADDED: Note that I avoided hard links after that, because I was worried about what would happen if I modified one file and deleted it, thinking it was a link to another, when it was actually a copy. A person could lose a lot of work if that happened. At least with a symlink, I know that something is or is not a link.
That's rather the point. When presenting a view of the file system under some particular directory, it's nice to not have to hard-link every file into place, and instead include wholesale directory trees. That's my most common use case for symlinks.
It's mitigated in that you can't hard link a directory (except in recent MacOS). So I suppose you would always know the real cwd of your shell, for instance.
Every command that operates on files needs an extra flag to tell it whatever it should follow symlinks, or operate on the target, or on the symlink itself, etc.
Any program that manipulates or traverses file trees is affected, and a few more, in an OS that is built around the concept of hierarchical file systems, this is quite a few.
>Symbolic links make the Unix file system non-hierarchical, resulting in multiple valid path names for a given file. This ambiguity is a source of confusion, especially since some shells work overtime to present a consistent view from programs such as pwd, while other programs and the kernel itself do nothing about the problem.
etc etc.
filesystems are a mess, and it'd be great if something could fix them.
He said they weren't added with proper appreciation of the Unix model and its simplifications. So he could mean that symlinks can be implemented in a more Unixy way?
