Linux – How does one inspect the directory structure information of a unix/linux file

Given the vast array of file systems out there, I'm certain that exceptions exist, but traditionally, the inode had an array of disk block numbers in it.

For example, in /usr/include/linux/ext3_fs.h, I see a definition of struct ext3_inode.

Inside struct ext3_inode, I see a member i_block[EXT3_N_BLOCKS];/* Pointers to blocks */

Different file systems have had different ways of keeping track of which disk blocks belong to an inode (the on-disk data structure that represents the file's data). Some have an array of block numbers, some have an array of runs or extents, a count plus the beginning block number of a run of contiguous blocks. The Berkeley FFS inode had an array of block numbers, and array of block numbers, each of those blocks contained data block numbers, and a block number that contained block numbers that contained data block numbers.

The whole thing gets a bit weirder for "log structured file systems", but those are the exception rather than the rule.

Hard links to directories aren't fundamentally different to hard links for files. In fact, many filesystems do have hard links on directories, but only in a very disciplined way.

In a filesystem that doesn't allow users to create hard links to directories, a directory's links are exactly

1. the . entry in the directory itself;
2. the .. entries in all the directories that have this directory as their parent;
3. one entry in the directory that .. points to.

An additional constraint in such filesystems is that from any directory, following .. nodes must eventually lead to the root. This ensures that the filesystem is presented as a single tree. This constraint is violated on filesystems that allow hard links to directories.

Filesystems that allow hard links to directories allow more cases than the three above. However they maintain the constraint that these cases do exist: a directory's . always exists and points to itself; a directory's .. always points to a directory that has it as an entry. Unlinking a directory entry that is a directory only removes it if it contains no entry other than . and ...

Thus a dangling .. cannot happen. What can go wrong is that a part of the filesystem can become detached. If a directory's .. pointing to one of its descendants, so that ../../../.. eventually forms a loop. (As seen above, filesystems that don't allow hard link manipulations prevent this.) If all the paths from the root to such a directory are unlinked, the part of the filesystem containing this directory cannot be reached anymore, unless there are processes that still have their current directory on it. That part can't even be deleted since there's no way to get at it.

GCFS allows directory hard links and runs a garbage collector to delete such detached parts of the filesystem. You should read its specification, which addresses your concerns in details. This is an interesting intellectual exercise, but I don't know of any filesystem that's used in practice that provides garbage collection.