21

I am reading this intro to the command line by Mark Bates.

In the first chapter, he mentions that hard links cannot span file systems.

An important thing to note about hard links is that they only work on the current file system. You can not create a hard link to a file on a different file system. To do that you need to use symbolic links, Section 1.4.3.

I only know of one filesystem. The one starting from root (/). This statement that hard links cannot span over file systems doesn't make sense to me.

The Wikipedia article on Unix file systems is not helpful either.

28

Hopefully I can answer this in a way that makes sense for you. A file system in Linux, is generally made up of a partition that is formatted in one of various ways (gotta love choice!) that you store your files on. Be that your system files, or your personal files... they are all stored on a file system. This part you seem to understand.

But what if you partition your hard drive to have more than one partition (think Apple Pie cut up into pieces), or add an additional hard drive (perhaps a USB stick?). For the sake of argument, they all have file systems on them as well.

When you look at the files on your computer, you're seeing a visual representation of data on your partition's file system. Each file name corresponds to what is called an inode, which is where your data, behind the scenes, really lives. A hard link lets you have multiple "file names" (for lack of a better description) that point to the same inode. This only works if those hard links are on the same file system. A symbolic link instead points to the "file name", which then is linked to the inode holding your data. Forgive my crude artwork but hopefully this explains better.

image.jpg             image2.jpg
          \           /
           [your data]

here, image.jpg, and image2.jpg both point directly to your data. They are both hardlinks. However...

image.jpg    <-----------  image2.jpg
           \ 
             [your data]

In this (crude) example, image2.jpg doesn't point to your data, it points to the image.jpg... which is a link to your data.

Symbolic links can work across file system boundaries (assuming that file system is attached and mounted, like your usb stick). However a hard link cannot. It knows nothing about what is on your other file system, or where your data there is stored.

Hopefully this helps make better sense.

  • Thanks. I didn't realize different file-partitions are called "file systems." – Anton Paras Jun 18 '16 at 6:37
  • 1
    one of the things you can do with a partition is put a filesystem on it, there are other places you can put filesystems and other things you can do with partitions, but the most-common option is that one. – Jasen Jun 18 '16 at 9:53
  • 10
    There's one file hierarchy that starts at "/". It will have one or more file systems mounted – mpez0 Jun 18 '16 at 21:29
  • @mpez0: Not even, with e.g. chroot(2) or real containerization you can have multiple hierarchies, which may have nothing whatsoever to do with each other. – Kevin Jun 19 '16 at 5:40
  • @Kevin,chroot isolates a portion of the hierarchy for a process and its descendants, but the parent still has one complete hierarch. Containerization may do it, depending on how close to a VM it is. But how much detail can one pack into a comment? Thanks, – mpez0 Jun 20 '16 at 12:12
22

The File system is composed by a directory structure composed for directory entries to organize files. Each directory entry associates a file-name with an inode.

Soft links (symbolic) are directory entries that does not contain data, it just points to another entry (a file or directory in the same file system or other file system). And when you delete the pointed file, the symbolic link becomes unusable.

Hard links are directory entry that contains the file name and inode number. When you remove the last hard link, you can no longer access the file.

Difference between soft-link and hard-link

Conclusion:

As the inode is a data structure used to represent a file-system object, it's internal to the File system, and you can't point to an inode of another file system.

Thus, hard-links are only valid within the same File system, but soft-links (Symbolic link) can span file systems as they simply point to another directory entry (The interface of the file-system, and not an internal object).

  • 1
    Nice concise answer. – dubkat Jun 18 '16 at 6:46
  • What will happen if another file system (let's say USB) will have a file with the same NAME, to which our symbolic link is connected on our file system? – Josef Klimuk Apr 29 '18 at 10:11
  • @JosefKlimuk, a soft link would point to a path, let's say /mnt/myfile. If you mount another file system into /mnt/. The soft link would be resolved to an entry of the mounted file system under /mnt/. Thus, if you mounted the file system from your USB device on /mnt, the soft link would resolve to an entry on that file system. – Facundo Victor Apr 29 '18 at 18:57
2

The root filesystem can be made up of several filesystems; /usr/local might be mounted on a separate partition and /home might be on another partition on a networked disk somewhere else. In this case, a hard link for /usr/local/bin/git (for example) may not be created outside of /usr/local, because it would span filesystems.

The reason for this is that the inodes are allocated separately for /, /usr/local and /home (again, in this example), and when you create a hard link you really just make an additional name for an inode.

2

Hard links have the effect of keeping their target alive. As long as any hard link is reachable, the system will ensure that its target cannot get released. It is therefore necessary that all media that could contain hard links to a particular inode be mounted any time the system would be trying to determine whether any references exist to it.

Given that inode lifetime is usually determined by maintaining reference counts rather than scanning for references, it might be possible to arrange things to that two or more file systems that held links to each other could be used independently provided there was no need to use links which bridged between the systems, and provided there was no need to use fsck on either one. If inode counts on one of the systems got disturbed, however, the only way to make that system useful again would be to use a form of fsck operation which could scan both file systems for references. Because of that constraint, while it might be possible to allow two inter-linked file systems to be usable independently, the benefits of doing so would probably be too limited to make it worthwhile.

  • Good point, but a bit too tangential to be good answer. – Joe Jun 25 '16 at 3:21
  • @Joe: Allowing hard links to cross file systems would impose a number of technical difficulties, but most of them could be overcome, thus raising the question of whether there's any compelling reason why they shouldn't be. The keep-alive issue may seem obscure, but unlike the other issues it can only me resolved by imposing severe semantic restrictions on the usage of such links, which would severely limit their value. – supercat Jun 25 '16 at 13:15
  • Good point. A filesystem can be mounted on another device and modified, so the inode and links can get "out of sync". Every filesystem could have a GUID and the link could incorporate that GUID to track the inode across filesystems. There could also be some sort of log on the FS and then when it is mounted, the host system would not need to scan it but could just read the log and "catch up" on the inode linking changes (When do we clear it, though?). Bottom line is the underlying FS would need to be modified in non-trivial ways and it would only work across compatible filesystems. – Rolf Feb 20 '18 at 12:54
1

A single inode number use to represent file in each file system. All hard links based upon inode number. File system reference link here .

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.