12

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?

Gilles 'SO- stop being evil'
  • 44,159
  • 8
  • 120
  • 184

4 Answers4

2

You get fewer special cases. In many situations, VFS may handle ".." as it handles any other directory name.

rgrig
  • 1,346
  • 1
  • 11
  • 15
2

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.

svick
  • 1,876
  • 14
  • 15
2

The only reason I can imagine is the following scenario:

  1. An original implementation of a file system existed with the same directory format but the notions of file paths and subdirectories was not considered at that time (See The PDP-7 Unix file system).

  2. Then people thought that path resolution and subdirectories would be useful!

  3. To keep some amount of backward compatibility with older implementations, it was decided that the . and .. will be stored on the disk just like any other directory.

So maybe we're left with those useless artefacts, just for the sake of backward-compatibility with 40 years old software? Credible scenario?

Note: Also it was not completely stupid to add these entries to the directory listing, as you need to store the inode number of your true parent directory somewhere anyway (remember that hardlinks on directories was allowed at this time), and a reference to your own inode number might be a good sanity check.

Stéphane Gimenez
  • 1,490
  • 1
  • 14
  • 29
1

I don't see a reason to implement . and .. on either level rather than the other. However, if you target embedded systems any layer you can save may be dollars earned, so it might make sense to try and implement everything as low as possible.

As for the general need of . and .., how would you express relative paths without them? At least .. is indispensable for paths that leave the current subtree. If you do not need such paths (maybe the tree is a primitive way to encode access privileges?) you do not need ...

Raphael
  • 73,212
  • 30
  • 182
  • 400