9

I'm aware that this article exists: Why are hard links only valid within the same filesystem? But it unfortunately didn't click with me.

https://www.kernel.org/doc/html/latest/filesystems/ext4/directory.html I'm reading operating system concepts by Galvin and found some great beneficial resources like linux kernel documentation.

There can be many directory entries across the filesystem that reference the same inode number--these are known as hard links, and that is why hard links cannot reference files on other filesystems.

In the very beginning the author says this. But I don't understand the reason behind it.

Information contained in an inode:

  • Mode/permission (protection)
  • Owner ID
  • Group ID
  • Size of file
  • Number of hard links to the file
  • Time last accessed
  • Time last modified
  • Time inode last modified

https://www.grymoire.com/Unix/Inodes.html

Now since the inode contains these information, what's the problem with letting hard links reference files on other filesystem?

What problem would occur if hard link reference on other filesystems?

About hard link:

The term "hard link" is misleading, and a better term is "directory entry".

A directory is a type of file that contains (at least) a pair considering of a file name and an inode. Every entry in a directory is a "hard link", including symbolic links. When you create a new "hard link", you're just adding a new entry to some directory that refers to the same inode as the existing directory entry.

enter image description here

This is how I visualize what a directory concept looks like in an operating system. Each entry is a hardlink according to the above quoted text. The only problem that I can see is that multiple filesystem could have same range of inode(But I don't think so as inode is limited in an operating system).

Also why would not it be nice to add new information about filesystem in inode itself? Would not that be really convenient?

5
  • 4
    "multiple filesystem could have same range of inode(But I don't think so as inode is limited in an operating system)" -- in traditional unixy filesystems (incl. eg. ext4), inode numbers are simple indexes to the table of inodes, i.e. they start from zero in each FS instance and hence always overlap. In some other cases (VFAT) with no real inodes, the OS fakes some inode numbers to give to userspace
    – ilkkachu
    Sep 17, 2023 at 12:34
  • inodes also contain the beginning of the list of disk blocks (relative to the beginning of the filesystem/partition) that hold the file's data. Disk block numbers have different interpretations to other filsystems. Each filesystem starts numbering its disk blocks at 0, and has no way to refer to disk blocks on the other filesystem.
    – waltinator
    Sep 19, 2023 at 3:18
  • What do you expect to happen when you unmount that other filesystem? Should the current filesystem unmount as well, or become invalid? And if two filesysems have to always behave as one, then what's the benefit of having them separated? Sep 19, 2023 at 8:33
  • A hard link is just another name for a file, how would a completely different filesystem be able to create a new name for a file that resides in a different filesystem? Sep 20, 2023 at 1:34
  • 1
    Does this answer your question? Why are hard links only valid within the same filesystem?
    – AdminBee
    Sep 21, 2023 at 13:47

5 Answers 5

37

A "hard link" just is the circumstance that two (or more) entries in the hierarchy of your file system refer to the same underlying data structure. Your figure illustrates that quite nicely!

That's it; that's all there is to it. It's like if you have a cooking book with an index at the end, and the index says "Bread: see page 3", and "Bakery: see page 3". Now there's two names for what is on page 3.

You can have as many index entries that point to the same page as you want. What does not work is that you have an index entry for something in another book. The other book simply doesn't exist within your current book, so referring to pages in it just can't work, especially because different versions of the other book could number pages differently over time.

Because a single filesystem can only guarantee consistency for itself, you cannot refer to "underlying storage system details" like inodes of other filesystems without it breaking all the time. So, if you want to refer to a directory entry that's stored on a different file system, you'll have to do that by the path. UNIX helps you with that through the existence of symlinks.

The only problem that I can see is that multiple filesystem could have same range of inode(But I don't think so as inode is limited in an operating system).

That's both untrue and illogical: I can ship you my hard drive, right. How would I ensure that the file system on my hard drive has no inode numbers you already used in one of the many file systems that your computer might have?

Also why would not it be nice to add new information about filesystem in inode itself? Would not that be really convenient?

No. Think of a file system as an abstraction of "bytes on storage media": a file system in itself is an independent data structure containing data organized into files; it must not depend on any external data to be complete. Breaking that will just lead to inconsistencies, because independence means that I can change inode numbers on file system A without having to know about file system B. Now, if B depended on A, it would be broken afterwards.

0
31

The challenge with this question is that it's based on a falsehood. It's based on the idea that such a thing would be impossible under any circumstances. It's easy to imagine how this might work, so it's useless trying to explain why it's impossible.

There are two problems you'd need to overcome. And these problems are enough to put off OS developers from trying to implement it.


The first would be how you reference which other file system a hard link points to.

In a running OS, each mounted filesystem can be allocated a unique number. This lets the OS know which mounted filesystem is responsible for which inode. But these numbers are only valid for the duration of the mount. If the OS is rebooted or the filesystem is unmounted (moved, unplugged, ...) then the number can change.

Hypothetically, you could use the UUID of the filesystem, but the reliability of that would be questionable. Duplicate UUIDs happen for file systems because of cloning and migration.

While it's not impossible, doing this would result in undue coupling of design between filesystem drivers for different file systems, and many developers would be strongly opposed to that.


The second problem is that the filesystem itself needs to know how many links exist on a file. Filesystems only delete a file when there are no links left. Filesystem checks need to ensure reference counts are correct, so would need to store external reference counts inbound. But there's no guarantee both file systems will be always mounted together to maintain the count.

If the filesystem stores those references, holding onto files and not just deleting them because another filesystem holds the hard link, what happens when the other filesystem is erased or otherwise destroyed?

Now you'd need an administrative action to remove them without access to the external filesystem. And that would be a very dangerous tool indeed.

In general filesystem checks which audited and corrected external links would be hard to achieve and mismatches common because of mounting one FS and not the other.

4
  • 5
    The problems with deleting files is a quite good point, that I hadn't even thought of when I read the title of this question and thought "there are many problems with that, I want to see if anything interesting is mentioned. +1. Sep 17, 2023 at 22:31
  • "how you reference which other file system a hard link points to"... which UUIDs could actually do easily. I'm not sure those were around when early POSIX-like file systems were developed, though. In any case, it's the second problem that properly puts the kibosh on the idea. Maybe something in between a hard link and a symbolic link would be possible, but whether it's an improvement over a symbolic link is questionable.
    – Matthew
    Sep 18, 2023 at 2:49
  • Regarding UUIDs, in addition to what you wrote, a UUID for a partition can be changed (I've done it myself). Sep 18, 2023 at 4:38
  • OS developers have not been put off from implementing it. Macintoshes have "aliases" which are like hard links not limited to the current file system. Linux has bind mounting which provides similar functionality.
    – Kaz
    Sep 20, 2023 at 4:03
6

What is a hard link

You are mixing up inodes and inode-references. A hard-link is an inode-reference.

A hard-link does not exist, there is no such thing. At least not as symbolic links exist. Every file has as least one. They are just file references.

Could you have a hard-link to another file-system.

No

As @MarcksMüller said, a page number refers to a page in this book.

Yes

But it would not be the same thing: it would not be a hard link.

You could use a symbolic-link. Or, someone could implement a new file type that links using a UUID/inode-number, or UUID/file-path. I don't know if this already exists, but have not seen it (I think NTFS may have it).

notes on your question

Your diagram looks correct.

However, your assertion that inodes must be unique is wrong. Imagine moving a USB connected device from one computer to another. It must work, but will probably use same inode numbers as an existing device.

9
  • Could you elaborate your #notes on your question?
    – achhainsan
    Sep 17, 2023 at 11:47
  • 2
    @achhainsan How does computer A know the i-node numbers used by B, so that it can avoid them? Sep 17, 2023 at 17:49
  • I tried to design a system that allowed it; and even solving the device identity problem it was problematic. The unsolvable problem is a hard link on a removable device that may or may not exist anymore.
    – Joshua
    Sep 17, 2023 at 19:16
  • I think devices have a UUID (so this part is solved). Sym-links can point to places than don't exist, so that is solved. We would just need to add a new file-type, and implement it in the VFS. Sep 17, 2023 at 19:19
  • 2
    see ntfs junctions for the only implementation that I know of learn.microsoft.com/en-us/windows/win32/fileio/… Sep 17, 2023 at 19:22
2

In a POSIX-like file system, you have two distinct things: You have real files - some data stored on your hard drive, and an inode describing the location and size of the data. And directory entries - describing a path, and a reference to a real file.

When you create a file in the file system, you actually create a real file, and a directory entry with a reference to that file's inode, in other words, a hard link. You can then create more additional hard links, that refer to the same inode. You can also create references to inodes by opening a file; that reference will stay as long as the file is opened. You use a directory entry to locate the inode when you open a file; if there is not just one hard link but multiple directory entries for the same real file, then you can use any of them.

Now with references to an inode, these references are counted. The real file with its inode are destroyed when the last reference goes away. The unlink function deletes a directory entry and removes the reference to its inode; the real file and the inode get deleted when the last directory entry is deleted. Unless the file is opened - the inode and data for an opened file are only deleted when the file is closed. You can even create a file without a directory entry, write to it, read from it, and it will be deleted when the file is closed.

What does this have to do with external file systems? The file system containing an inode and file MUST know about all references to the inode. If you created a file on your external hard drive, then created two additional hard links on your built-in hard drive, then unplugged the external drive, then the inode on the external drive cannot know about the references. I can create an additional hard link on my external drive. I can delete the two additional hard links. The external drive won't know the correct reference count and go wrong.

That's what you have soft links for. A soft link contains a description telling you how to find a directory entry for a file. That description can point to an external file system without any problems. Or it just contains an absolute path, that would be a path on the same file system as the soft link. Or it contains a relative path, relative to the directory entry of the soft link. So you have no problem if the external drive is unplugged (accessing files through a soft link may fail), or if the file got deleted (soft links don't keep a file alive); accessing the file will just fail.

1
  • It feels cluttered reading this. Do you have illustrations to elaborate? Only if you care to!
    – achhainsan
    Sep 18, 2023 at 13:21
-4

I'm not trying to answer your question, but...

Every entry in a directory is a "hard link", including symbolic links.

That's wrong.

Actually, the first part is right. Every entry in a directory is a hard link. But, a symbolic link is not an entry in a directory. A symbolic link is a file, just like any other file, except a flag in its inode tells the OS that when a program tries to access the symlink, the OS should treat the access specially.*

The author probably knew that, but they were trying to explain hard links, not symbolic links, and they got lazy. If they were less lazy, they might have said,

Every entry in a directory is a hard link. Even the entry for a symbolic link (a symbolic link actually is a special kind of file) is a "hard link" to the symbolic link file.


* The special treatment, when a program tries to access a symlink,** is;

  1. open the symlink file,
  2. read a pathname from the symlink file,
  3. close the symlink file,
  4. access the target file (i.e., the file named by the pathname that was read from the symlink file) as if that was the file that the program asked to open in the first place.

If the target file turns out to be another symlink, then the process repeats, either until a non-symlink file is found, or until the ELOOP error code is returned.


** There are a few system calls and/or options in system calls that don't "follow" symbolic links. Those are necessary because otherwise, how could any program (e.g., ls) ever give you information about symbolic links, or create or destroy symbolic links?

4
  • No, that first quoted sentence is right, hard links are essentially the same as directory entries, and there's a directory entry for every file, including directories and symlinks and what have you. The symbolic link part is different, but there's a hard link to every symlink in any case.
    – ilkkachu
    Sep 19, 2023 at 6:21
  • @ilkkachu, That's what I said, and it's different from what the text quoted by the OP said. You said, and I said, that a symbolic link is a kind of file. The quote says that a symbolic link is a kind of hard link/directory entry. Sep 19, 2023 at 12:03
  • Perhaps it could be phrased differently, it might be better said that every file has a directory entry pointing to it, or that "Every entry in a directory is a "hard link", including ones pointing to symbolic links.". But I don't think it's actually wrong wrt. the main point, that symlinks are just files, and hard links are names of files.
    – ilkkachu
    Sep 19, 2023 at 14:41
  • But that's not what the quote says. The quote asserts something about "every...hard link," and in that assertion it parenthetically adds, "including symbolic links." There's only one way to parse it, and if you didn't already know better, then you would conclude that a symbolic link must be a special kind of hard link. But, you and I both know that's not true. A symbolic link is a special kind of file, and while there is an intimate relationship between files and hard links, one which beginners do not immediately appreciate, they are not the same thing. Sep 19, 2023 at 14:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .