2

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?

2

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.

  • Thanks! I agree that your points are solid. As usually we are both correct and perhaps this "link" that I have in mind could exist with some new rules. As in my previous comment I would really like if symlinks would get updated automatically when files where moved (inside the same filesystem) and also have the performance of a hardlink. – Georgios Pligoropoulos Jun 28 '15 at 10:42
  • 2
    @GeorgePligor but why? If you want them to be updated when files are moved, use a hardlink. If you want them to be relative, use a softlink. You can't have it all and I still don't understand why in the world you would want to. It's like wanting all hammers to also be screwdrivers. – terdon Jun 28 '15 at 13:32
  • @terdon Thanks for challenging the idea. I must repeat the important part where the symlink gets updated automatically when you move the target files. Is this something you find bad practice or you simply didn't get it? I can update the question if it's not clear – Georgios Pligoropoulos Jun 28 '15 at 14:20
  • 1
    @GeorgePligor I don't get it. Sometimes I want that to happen, so I use a hardlink. Other times, I don't want it to happen so I use a softlink. I don't see how we would gain anything other than a slower filesystem if we were to try and combine the two. End users need never know about hardlinks but why would you deprive power users of their functionality? More importantly, remember that all files are hardlinks, how would what you describe even work? The entire point of a symlink is that it's not actually pointing to an inode like a regular file (a hardlink). – terdon Jun 28 '15 at 14:25
  • 1
    @GeorgePligor precisely: sometimes, not always. That's why I wouldn't want this to happen always. If I want it, I use hardlinks . – terdon Jun 28 '15 at 16:07
8

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.

  • Thanks for your thorough explanation. Maybe there is some case that hardlinks are really useful but haven't occured in my professional life. What would be more awesome though is that inside a filesystem if you had both a link to the inode and a link to the path of the target file, you could automatically update the relative path when the target file is moved, no? Ok I understand some extra work needs to be done from the operating system but it still makes it a nice abstraction for the end-user who does not need to recreate symlinks – Georgios Pligoropoulos Jun 28 '15 at 10:37
  • @GeorgePligor the end user might not but the sysadmin most certainly does. You do have both a link to the inode and a link to the path: hardlinks and symlinks :) – terdon Jun 28 '15 at 10:48
  • Without hardlinks you could not even navigate your filesystem... or open any files if that matters. – Sampo Sarrala Jun 28 '15 at 23:04
3

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.

  • @Sampo Sarrala I edited slightly, it's hard to explain without a drawing. What I mean is if a directory has, say 5 subdirectories, it will have a total of 7 filenames: the name you gave it (located in its parent), "." (located in itself) and 5x".." (on in each subdirectory). – spectras Jun 28 '15 at 23:07
  • Very good explanation. That small change made it very clear. I think that you won't need charts anymore :) Great answer. – Sampo Sarrala Jun 28 '15 at 23:11
2

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

1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.