Hardlinks vs. Softlinks

What do we learn from the history of UNIX hardlinks vs. softlinks?

First, UNIX hardlinks did not really help much for directories, because of the implicit assumption of hierarchy. ".." is the parent directory, but what if you have multiply parents?  What if things pount to each other?   You can force directory hardlinks given root, but it is a great way to get screwed up.  I think that on some systems it was possible to create cycles that could lead to inodes being garbage, not refrrable. Memory leaks.

LEARNINGS: be careful.

LEARNING?:  it may be "nice" to have a primary hierarchy, like .. for parent.   But it may also be that we just don't really have the concepts to deal properly with more general graphs.

It was (is) much easier to deal with UNIX hardlinks to files.

But... one could get messed up because rm removed a link to an object, but did not actually remove the object itself.

LEARNING: there must be a way to say "remove the object completely", not just the link.  Hmm... perhaps a notation like "rm ab/b" removing a link, "rm a/b/." removing the object itself.  BTW, I often think of all objects as being directories  Internal structure.

Big problem with hardlinks is not being able to link across filesystems.   No matter how comprehensive your database is, there will always be stuff outside your database.  You will need to link to this outside stuff.   But...  perhaps you can provide all of the goodness of labels, paths, reflexity, etc., for this outside stuff you link to as well as the inside stuff?

Symlinks helped with many of the manageability problems of hardlinks.  At the cost of making things even harder to set up.  (Have you ever managed link farms? ...)

With symlinks, there must be a primary name.

When you move the primary object, symlinks go dead.

(LEARNING: permalinks, etc.)

Symlinks do not really resolve the "how do you remove the object" problem.  You just have to find the non-symlinked name. With hardlinks, there isn't really a non-symlinked name.