by mfrw on 5/31/25, 8:57 AM with 38 comments
by the_mitsuhiko on 6/2/25, 8:51 AM
> The root inode is the root of the file system. Inode 0 can't be used for normal purposes and historically bad blocks were linked to inode 1 (inode 1 is no longer used for this purpose; however, numerous dump tapes make this assumption, so we are stuck with it). Thus the root inode is 2.
This is also echoed on the wikipedia page for it.
The linux Kernel also has this comment for why it does not dish out that inode for shmem for instance:
> Userspace may rely on the the inode number being non-zero. For example, glibc simply ignores files with zero i_ino in unlink() and other places.
On macOS it's pretty clear that inode 0 is reserved:
> Users of getdirentries() should skip entries with d_fileno = 0, as such entries represent files which have been deleted but not yet removed from the directory entry
by jcalvinowens on 6/2/25, 2:57 PM
It turns out that glibc readdir() assumes inode zero doesn't happen and the files are "invisible" to anything using libc. But you can call getdents() directly and see them.
I actually ran into this on a production machine once a few years ago, a service couldn't restart because a directory appeared to be "stuck" because it had one of these invisible zero inode files in it. It was very amusing, I figured it out by spotting the invisible filename in the strace output from getdents().
by nulld3v on 6/2/25, 8:29 AM
by Animats on 6/2/25, 7:04 AM
by duckerude on 6/2/25, 1:02 PM
A file descriptor can't be -1 but it's not 100% clear whether POSIX bans other negative numbers. So Rust's stdlib only bans -1 (for a space optimization) while still allowing for e.g. -2.
by etbebl on 6/3/25, 4:03 AM
Am I missing something or is this just evil? I guess I'm taking it too seriously.