Consider an filesystem targeted at some embedded devices that does little more t
ID: 646919 • Letter: C
Question
Consider an filesystem targeted at some embedded devices that does little more than store files in a hierarchical directory structure. This filesystem lacks many of the operations you may be used to in systems such as unix and Windows (for example, its access permissions are completely different and not tied to metadata stored in directories). This filesystem does not allow any kind of hard link or soft link, so every file has a unique name in a strict tree structure.
Is there any benefit to storing a link to the directory itself and to its parent in the on-disk data structure that represents a directory?
Most unix filesystems have . and .. entries on disk. I wonder why they don't handle those at the VFS (generic filesystem driver) layer. Is this a historical artifact? Is there a good reason, and if so, which precisely, so I can determine whether it's relevant to my embedded system?
Explanation / Answer
Having links to the parent directory makes good sense to me. If you didn't have them, you would always need to work with a whole list of directories. So, for example, /home/svick/Documents/ would have to be represented as { /, /home/, /home/svick/, /home/svick/Documents }. If you didn't do that, you wouldn't be able to find the parent directory at all (or it would be very expensive). This is not only inefficient, but also dangerous. If you have two such lists that overlap, they could easily desynchronize if you moved some directory.
On the other hand, if you have a reference to the parent directory, it's more efficient and safer.
I don't see any reason to actually have a link to the current directory. If you have a structure that represents some directory and you want to access that directory, using . is always completely unnecessary. Because of that, I would expect that the . link doesn't actually exist in the filesystem structure and is only virtual.