MongoDB – File System Implementation with GridFS

The easiest is to have a hash table per directory. To follow a pathname, just get the root hash table, query it for the first directory in the path. Then, if it's a directory, get the next hash table and query it with the next part, and so on until the last part.

Since hash tables are unordered structures, you would typically sort them in memory to list a whole directory. Also, the hash wouldn't help to match wildcards; you have to do a whole directory scan to see which names match a given pattern. Of course, an ordered structure (like a sorted list or a B*tree) only help if there's a constant prefix.

A different way (used by Mac's HFS system) is to use an ordered structure (a B*tree in HFS case) and index by directory/name. In HFS, there was a dirID/filename structure that served as the main key for a single B*tree. Once you had this file handle, a single query returned the directory entry, without having to traverse the whole pathname. To get a directory list, just read the range [dirID, dirID+1), the resulting interval comprised all the filenames stored in that directory, in binary lexicographical order.

There is no single structure which can fit all the cases. For example, if I compare the tree you quoted in your question with a web application I'm currently working on, it doesn't fit. For example, they separate static pages, while the separation between static and dynamic pages makes no sense in my context of my current app. They create a separate directory for CSS, while I have a single stylesheet which I put at the root and am happy to find it there. I don't have includes, but helpers and something comparable to partial views, etc.

If you create an application which stores and displays events, the logical structure would be by year, then by month, and finally by day.

If you create an application which has three logical parts in it, it should be reflected in the tree.

Also remember that actual file tree is only a tiny part of the project structure; for example, in ASP.NET MVC, nothing forbids you from creating your own virtual path provider and host data in a database rather than as files if it is more convenient and easy to understand for you and other developers who will work on your project later.

Sticking to a file structure some team invented to fit precisely their project needs is not a good idea in this regard.