RE: [boost] Re: Design for a file system library

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-03-07 16:21:54

From: bill_kempf [mailto:williamkempf_at_[hidden]]
> 
> --- In boost_at_y..., "Stewart, Robert" <stewart_at_s...> wrote:
> > You can't assume which directory makes sense for root_directory().  
> If a PC
> > is booted from a floppy, then "A:\" may be correct.  If a system is
> > configured to do its initial boot from one device and then switches 
> to
> > another, then the root directory of some other drive is the correct 
> value
> > for root_directory() to return.  Consequently, I think that this 
> concept
> > must be handled separately.
> 
> I don't consider "root" to be the drive booted from.  In fact, I 
> rarely have a need to determine what drive was booted from.  I think 
> that mapping root_directory() this way would lead to more confusion 
> and provide no help to developers.

We agree on that point.

> > What I mean is that on a drive letter-based filesystem, one must 
> determine
> > the correct drive letter by some extra-library or otherwise
> > filesystem-dependent means.  Once you have the correct drive 
> letter, perhaps
> > including the : and \, then the rest of the library under 
> discussion comes
> > to bear.
> 
> Why should I have to use some other library for finding the available 
> drive letters?  I don't agree with that, regardless of any decision 
> made on what "root" should mean on such systems.

I meant that the meaning of "root" must come from something other than we've
been discussing thus far.  That is, there must be platform-specific
libraries that provide the starting point for the portable filesystem
library to take over.  Thus, you create some object and call a mf or you
call some free function to ascertain the "root" directory for the filesystem
you wish to access.  Once you have that, you can create a
directory_iterator, etc., to do the rest of the work before you.

> > The point is that you can't coerce such wildly diverse concepts 
> into a
> > single function and get meaningful cross-platform behavior.  If I 
> am a Unix
> > developer and I called root_directory(), I'd expect a single value, 
> just as
> > I had always gotten from it.  If I found myself calling 
> root_directory() on
> > a PC-based filesystem, imagine my surprise to learn that I got back 
> some
> > sort of list of things rather than the one I had always gotten 
> before.
> 
> No, the proposal isn't quite what you're describing.  On a file 
> system that uses drive letters (or similar concepts) root_directory() 
> *still* returns a single value.  This value "refers" to a "directory" 
> that contains the entries for the various drives, the same as '/' on 
> POSIX would refer to a directory which would contain other elements.  
> The only difference would be that on Win32 "root" would be read-only.

You're right, I missed that.  However, the idea still doesn't fit well.  "/"
on a Posix system is a real directory that can contain files and
subdirectories, and can be modified, given suitable permissions.  On
Windows, what you're describing can only describe a pseudo-directory that
doesn't behave like a directory except that it can contain subdirectories.
To make the concepts parallel, "/" on a Posix system would need to provide a
pseudo-directory that contains a single entry: the "/" directory.

> BTW, Win32 systems already have this concept.  The "Shell Namespace" 
> uses SHITEMID identifiers, with "Desktop" as a root, which refers to 
> *all* items available in the shell (which includes all drives, all 
> printers, etc.).  So from a Win32 perspective I agree with Beman's 
> proposal, though I'd like to extend it to include all shell items, 
> including printers, etc.

May I suggest that on a Windows system one might create a "desktop" object
that gives one access to, among other things, the available, mapped drives.
From those, one could create directory_iterators, etc., to play with the
filesystem.  Likewise, one could create a "my_computer" object that provides
the contents of Windows' My Computer thingie.  This approach allows the
portable filesystem library to be extended to other platforms more easily
without shoehorning often incompatible aspects into it.

Rob
Susquehanna International Group, LLP
http://www.sig.com