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.
As such, it feels to me like a more natural way to work with the file system is through an object that represents trees, and functions that help you work with the tree, or represent a particular path on the tree as a generic string, with a particular separator character (or characters).
What are the separator characters in c:\x.txt, c:x.txt, or SYS$SYSDEVICE:[USER.DOCS]PHOTO.JPG:8? I claim that the "paths are strings" mindset is too simplistic, narrow minded and useless for defining path arithmetic. It is still true that we *do* want to represent paths as strings, and actually a library that would work with std::strings has its own right for existence. However, any paths library shall not have the word "separator" in its documentation for anything other than the platform specific parts. "SYS$SYSDEVICE:[USER.DOCS]PHOTO.JPG:7" / "[OTHER]DOCUMENT.TXT:8" == "SYS$SYSDEVICE:[USER.DOCS.OTHER]DOCUMENT.TXT:8" With that approach, you could also represent the Windows registry using the
same objects (just a different backend to handle the obviously different API calls). Or SMNP OIDs. Or a web site's paths.
Not really, the syntax is different. -- Yakov