On Sat, Mar 23, 2013 at 1:34 PM, Michael Marcin
Yakov Galka wrote:
On Sat, Mar 23, 2013 at 2:42 PM, Joseph Van Riper < fleeb.fantastique@gmail.com> wrote:
I have never seen a file system that wasn't, really, a tree with branches and leaves. It can have more than one base, but ultimately, it's a tree.
It is called a "forest". But filesystems aren't really forests. For starters, they are very often DAGs (you can hardlink the leaves). Much software assumes that path is a unique identifier of a resource and breaks on non-trees. If people would not make such assumption we could very well allow arbitrary graphs. The point is that there is no *a priori* reason
[...] that file systems are DAGs, it is the *result* of thinking of filesystems as trees of paths.
They can quite easily become non-DAGs with junction points / symlinks being able to create cycles.
Ah, yes, I had forgotten about hard or soft links (nod to Yakov Galka for this as well). I suppose those do need to be considered in some way if you wish to do more interesting things with this than the common use case. Still, in practice, people do not generally type in the underlying identifier for a node in the file system. While the system of using trees (or a forest, to include root nodes) to represent the file system might be broken, it is a dominant pattern. Resisting this pattern would most likely yield something that is not intuitive, despite the existence of items that do not fit the tree pattern. Even most APIs within operating systems that expose a file system use tree-like commands to work with the file system, with ways of going into sub directories, or parent directories, moving branches or leaves around, deleting said items, viewing the branches or leaves within a particular branch or root, etc. While I won't claim to be an expert on every file system in existence, I suspect most operating systems expose commands that work as if the underlying structure is a tree, despite the file system acting more like a graph, with the exception of the occasional command that links or unlinks to another node. At the very least, if I were on a command prompt, I wouldn't expect to find any command that allowed me to perform bulk operations within the file system with the mind-set of working a graph instead of a tree. For example, a command to find a particular file tends to have operations that look within sub-folders, not sub-graphs. And, yeah, I see where that leads to problems occasionally (when the file system forms a circle due to how the nodes are arranged), but I also see where most people seem to wave that off as, 'oh well, that's to be expected if you create circles in your file system'. I would offer that if you want to have a representation that uses a graph, you would still need to provide commands that match what you see in the operating system's api for working with the file system, which kind of brings you back to at least imitating a tree, rightly or wrongly, if you want the library to remain intuitive. - Trey