Re: [boost] [Filesystem] v3 path separator changes

On Sat, Mar 23, 2013 at 9:15 PM, Joseph Van Riper < fleeb.fantastique@gmail.com> wrote:

On Sat, Mar 23, 2013 at 1:34 PM, Michael Marcin

...

wrote: [...] 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.

Even if the FS would be an arbitrary graph, it does not mean that we must drop the path concept. The distinction between paths and FS graphs is important, and many people get it wrong. One key point observation is that a paths may have a meaning without an underlining filesystem. For example I may say "C:..\a.txt" and it means "the file named 'a.txt' in the parent directory of the current working directory of drive C". The above string is a sequence of *instructions* for locating a resource, which may not even exist. Some systems do expose those nodes in one way or another. In UNIX we have inodes, which I do not know much about. In Windows the NtCreateFile actually allows one to use a path relative to a previously opened handle. Now, this is not principle that this is not the API one usually uses. What does matter is that this is what we mean when we write a path and that it is what actually happens behind the scenes: the operating system parses the path into a sequence of path elements, each of which gives it a command to what node of the graph it must go next. This is the abstraction paths represent, and not "a string with some separators". One should dance from here. Some may ask how the way we look on paths changes the interface of a path library if we are going to store them in strings anyway? For an answer consider the the definition of operator / in current boost filesystem, which is defined syntactically and gives "c:" / "a" == "c:\a". Contrast it with a higher level one: a concatenation of the sequences of instructions, which would give "c:" / "a" == "c:a". For some more examples of bugs related to the syntactic definition of boost filesystem see the thread I linked earlier. -- Yakov