Why not design having the softlink (symlink) and hardlink in the same "link"?

Question

I haven't used hardlinks for a long time and never really needed them until I was asked in an interview. I read their difference from symlinks here: What is the difference between a hard link and a symbolic link?

Is there any particular reason why the design is not having both of the capabilities of the symlink and the capabilities of the hardlink in the same link file?

You want to point to a file. Ok so you start with a hardlink functionality to cover situations where the filename is changed or the file is moved. If hardlink is not valid because it refers outside the filesystem or fails for some other reason have a fallback, the filepath of that file to refer to, in other words have a symlink.

Because what the user of an operating system wants by the end of the day is just have a link to a file.

Is there anything that could prevent the above design solution for links?

Answer 1

I don't really understand what you mean. I think you have misunderstood what hard links are. First of all, all files are hardlinks. Every single one. A file is just a link pointing to an inode. A symlink, on the other hand, is a link pointing to a hardlink (to a path). How could the two be combined?

More to the point, the functionality is very different. Consider this:

$ echo "This is file" > file
$ ln -s file softlink
$ ln file hardlink
$ cat softlink 
This is file
$ cat hardlink 
This is file
$ rm file
$ echo "This is a different file" > file
$ cat softlink 
This is a different file
$ cat hardlink 
This is file

As you can see above, deleting the file a hardlink points to does not affect the hardlink since the hardlink is pointing to an inode. The softlink, on the other hand, is changed when the target is deleted and recreated since the new file is now pointing to a different inode.

Also, since hardlinks point to inodes and not filesystem paths, they cannot be relative. It is very often useful to have a symlink pointing to, for example, ../../foo. That way, we can move the whole directory structure somewhere else and rename anything we like but the link does not break. So, if we move to a different directory, a softlink will always point to a foo that is two levels up. A hardlink, however, will just point to whatever inode it was created to point to and moving the directory will not affect it. Sometimes that's what we want and sometimes it isn't. Having this kind of versatility is very useful.

Answer 2

I think you are confused by the word “link” in “hardlink”/“softlink”. Despite the apparent naming symmetry, those are completely different things.

• Soft links:

  If you come from some microsoft background, maybe it would be easier to say that : a softlink is pretty close to what a shortcut is. It is an (almost) regular file that has a pathname in it.

  Only difference is on Unix, the OS has some magic to redirect applications automatically. Namely, when an application open()s a file, the OS will check the S_IFLNK mode flag on the file - if it is set, it means it only contains a path to another file, and the OS will transparently redirect the call to that path.

• Hard links:

  A hard link is just a technical term for "filename". When you "create a hardlink" you're just adding a second name for the same file. The whole workflow looks roughly like this:

  • When you create a file, it gets a first filename automatically.
  • You may add additional filenames if you so wish.
  • You cannot actually delete files on Unix. The rm command only deletes a filename. This is much more obvious when you know the actual operation it performs is called unlink()ing
  • Whenever a file no longer has any filename, it gets deleted. (*)

  As a sidenote, directories always have at least two filenames: one in their parent, and one in themselves (.). Also, if a directory has subdirectories, it will have an additional hardlink in each subdirectory, named ...

  You may see the filename/hardlink count by running ls -l. Second column in the output.

(*): if some process is using the file, deletion is postponed until it's not used anymore. In the meantime, you do have a file with no name, which you cannot see or access.

Answer 3

I see the following disadvantages:

• with hard links there is no "original" path of the file anymore, i.e. you can't distinguish a file from its links. I often use links as shortcuts to files which are down in a well-sorted, nested directory structure, to simplify navigation, but I still want to be able to look up where exactly the file is stored (since its original path contains information).
• The fallback would make things confusing for less advanced users. If you get used to everything being hardlinked, and the file being a link itself, you might sometimes delete the file at the original location because you know that the links will keep the data on the drive. Now if the fallback to a soft link has occurred, you will delete your data. Of course the software could issue a warning, but for many that could increase confusion.

In general I don't think it's a good idea to hide fundamentally different things from the user. For most scenarios, soft links are fine. In my experience, hard links are mainly useful for backups. For example dirvish makes use of them.

Answer 4

The idea you describe exists already, in the form of the 'Alias' in Apple's HFS+ filesystem. If you create an alias for a file, then you can use that alias to refer to the file in future. The alias uses a mixture of inode-equivalent (HFS+ doesn't have inodes as such), file name, and... other stuff to re-find the file, using an algorithm which is deliberately undocumented.

Pragmatically – meaning, for most non-technical users – this works pretty well, because the sort of filename changes, and file moves, that people make in practice are handled well enough by this (DWIM and all that); and the undocumented nature of the resolution algorithm means that Apple has the freedom to tweak the heuristic if they find something that works better. This is a Good Thing, in principle. On the other hand, it annoys the hell out of anyone who'd prefer that their computers were deterministic, dammit! Apple doesn't currently seem to push the 'alias' in their technical documentation.

I think this comes under the heading of: interesting experiment – pushed hard – not ultimately rewarding.

[It's rather hard to find chapter and verse on HFS+ aliases (sc, I haven't been able to find any in 10 minutes of searching, just now), so if anyone does have specific references, feel free to edit this answer.]

Answer 5

Before I started using Unix I used AmigaOS which have links which both have some of the aspects of symlinks and of hardlinks. I never really got to understand how they behaved.

Then I got to use Unix systems (and later Linux). I found both symlinks and hardlinks easy to understand on their own. To this day I still don't understand the hybrid construction used for links in AmigaOS.

From a principle of least surprise, I find the distinction between symlinks and hardlinks to be a very good construction. Neither of them comes with any surprises.

But the two constructions are very different. The most significant aspect they have in common is that both can be created using the ln command line tool.

I cannot imagine how you would merge the two into a unified concept without making it immensely complicated. And that would be the primary argument against changing the design. It is better to have to separate features each of which is simple to understand than one complicated feature.

Another argument against the change is that there is a lot of software designed to work with symlinks and hardlinks as they work now. All that software would be unable to deal with a hybridlink.