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

Subject: Re: [boost] [Filesystem] v3 path separator changes
From: Yakov Galka (ybungalobill_at_[hidden])
Date: 2013-03-23 16:18:30

On Sat, Mar 23, 2013 at 9:15 PM, Joseph Van Riper <
fleeb.fantastique_at_[hidden]> wrote:

> On Sat, Mar 23, 2013 at 1:34 PM, Michael Marcin <mike.marcin_at_[hidden]
> >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