The main advantage of hard links is that, compared to soft links, there is no size or speed penalty. Soft links are an extra layer of indirection on top of normal file access; the kernel has to dereference the link when you open the file, and this takes a small amount of time. The link also takes a small amount of space on the disk, to hold the text of the link. These penalties do not exist with hard links because they are built into the very structure of the filesystem.
The best way I know of to see this is:
$ ls -id .
1069765 ./
$ mkdir tmp ; cd tmp
$ ls -id ..
1069765 ../
The -i option to ls makes it give you the inode number of the file. On the system where I prepared the example above, I happened to be in a directory with inode number 1069765, but the specific value doesn't matter. It's just a unique value that identifies a particular file/directory.
What this says is that when we go into a subdirectory and look at a different filesystem entry called .., it has the same inode number we got before. This isn't happening because the shell is interpreting .. for you, as happens with MS-DOS and Windows. On Unix filesystems .. is a real directory entry; it is a hard link pointing back to the previous directory.
Hard links are the tendons that tie the filesystem's directories together. Once upon a time, Unix didn't have hard links. They were added to turn Unix's original flat file system into a hierarchical filesystem.
(For more on this, see Why does '/' have an '..' entry?.)
It is also somewhat common on Unix systems for several different commands to be implemented by the same executable. It doesn't seem to be the case on Linux any more, but on systems I used in the past, cp, mv and rm were all the same executable. It makes sense if you think about it: when you move a file between volumes, it is effectively a copy followed by a removal, so mv already had to implement the other two commands' functions. The executable can figure out which operation to provide because it gets passed the name it was called by.
Another example, common in embedded Linuxes, is BusyBox, a single executable that implements dozens of commands.
I should point out that on most filesystems, users aren't allowed to make hard links to directories. The . and .. entries are automatically managed by the filesystem code, which is typically part of the kernel. The restriction exists because it is possible to cause serious filesystem problems if you aren't careful with how you create and use directory hard links. This is one of many reasons soft links exist; they don't carry the same risk.
Symbolic link files take more space. Hard linked files share the same inode; but a symbolic file is a pointer to the original (location).
Despite that, there are two caveats for hard links:
- Not all file system support hard links.
- Hard links cannot be applied for folders.
I guess you do not need to consider about the storage issue since in most of the cases they are trivial. In addition, there might be some tools helping you organize genres virtually (they may take advantages of virtual file systems).
Best Answer
Beware that many editors write to a temporary file and rename finally to the target file.
This will cause your hard-linking to be lost.