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

Subject: Re: [boost] [Filesystem] v3 path separator changes
From: Joseph Van Riper (fleeb.fantastique_at_[hidden])
Date: 2013-03-23 15:15:12

On Sat, Mar 23, 2013 at 1:34 PM, Michael Marcin <mike.marcin_at_[hidden]>wrote:

> Yakov Galka wrote:
>
>> 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.
>>
>>
> They can quite easily become non-DAGs with junction points / symlinks
> being able to create cycles.

Ah, yes, I had forgotten about hard or soft links (nod to Yakov Galka for
this as well).  I suppose those do need to be considered in some way if you
wish to do more interesting things with this than the common use case.

Still, in practice, people do not generally type in the underlying
identifier for a node in the file system.  While the system of using trees
(or a forest, to include root nodes) to represent the file system might be
broken, it is a dominant pattern.  Resisting this pattern would most likely
yield something that is not intuitive, despite the existence of items that
do not fit the tree pattern.

Even most APIs within operating systems that expose a file system use
tree-like commands to work with the file system, with ways of going into
sub directories, or parent directories, moving branches or leaves around,
deleting said items, viewing the branches or leaves within a particular
branch or root, etc.  While I won't claim to be an expert on every file
system in existence, I suspect most operating systems expose commands that
work as if the underlying structure is a tree, despite the file system
acting more like a graph, with the exception of the occasional command that
links or unlinks to another node.  At the very least, if I were on a
command prompt, I wouldn't expect to find any command that allowed me to
perform bulk operations within the file system with the mind-set of working
a graph instead of a tree.  For example, a command to find a particular
file tends to have operations that look within sub-folders, not sub-graphs.
 And, yeah, I see where that leads to problems occasionally (when the file
system forms a circle due to how the nodes are arranged), but I also see
where most people seem to wave that off as, 'oh well, that's to be expected
if you create circles in your file system'.

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.

- Trey