|
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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk