From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-02-26 10:29:25
At 04:29 AM 2/26/2002, Vladimir Prus wrote:
>Beman Dawes wrote:
>> I've written a design document for a file system library. See
>> It is still rough, but should serve to focus discussions.
>> Comments appreciated.
>The first thing is that it would be great to have some base filesystem
>which can be used to access different fs types. This would allow, for
>example, accessing regular filesystem and HTTP/WebDAV server in a uniform
> void do_something(const URL& url)
> file_system* fs;
> if (url.scheme == "file")
> fs = new posix_file_system(....);
> if (url.scheme == "http")
> fs = new http_file_system(....);
> // do something with fs.
>This will be impossible without a base class.
A major requirement for a file system library is to work with the current
standard's I/O file open and construction. Since the standard doesn't
provide for any other kinds of files beyond whatever the operating system
considers to be a file, it seems to be over-design to provide for URL's and
the like as an explicit part of this library. That was a deliberate
decision; I should have documented it better.
Also, as a number of people in prior discussions pointed out, concepts like
"posix_file_system" are very slippery. What happens when a NTFS or ISO
9660 file system is mounted in directory on a POSIX machine, for example?
>And a minor question: path operations include "stripping a leaf", which
>not the same as getting a parent.
That is correct, and deliberate. The branch and leaf operations are
lexical only. That is, they operate on the contents of the string rather
than on an actual directory tree.
Getting a parent may be a useful operation, but it has complex semantics
that I haven't tried to specify. Does the path have to exist? If the path
doesn't exist, but the parent can be determined lexically, should the
operation still succeed?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk