Boost logo

Boost :

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

On Sat, Mar 23, 2013 at 2:42 PM, Joseph Van Riper <
fleeb.fantastique_at_[hidden]> 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

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.


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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at