Re: Design for a file system library

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-03-06 10:52:32

--- In boost_at_y..., "Stewart, Robert" <stewart_at_s...> wrote:
> From: Jan Langer [mailto:jan_at_l...]
> > 
> > On Tue, 5 Mar 2002, Beman Dawes wrote:
> > >
> > > > eg. if i want to write
> > > >something to the root directory. it would not be allowed 
> > on win32. but
> > > >if i call directory_iterator (root_directory ()) it fits for 
win32
> > > >("c:") but not for posix ("/bin").
> > > >a hierarchy_iterator however returns "/" on posix and "c:" 
> > on win32.
> > >
> > >I was assuming directory_iterator( root_directory() ) would 
> > return all the
> > >directory_entry's in "/" for POSIX, and a:,b:,c:, etc for win32.
> > 
> > yes, but this is not what most users would expect. i think 
posix's '/'
> > corresponds to win's 'c:' and posix's '/bin' corresponds to wins
> > 'c:\Windows\'. of course i mean only the level in the hierarchy.

You *might* argue that posix's '/' is equivalent to 'c:', though as 
pointed out below this is at least a bit of a stretch.  However, I 
*really* don't think you can consider '/bin' to be 'c:\windows'.

1) Some people install the OS on a drive other then C:.  For various 
strange reasons (not all valid) I have it installed on G: at home.

2) The directory isn't allways named "windows".  On most of the 
systems I've used it's been named "winnt".

3) Since Win2K the "windows" directory has been restricted heavily 
and you can't (and never should have) install anything into this 
directory sub-tree.

In fact, other then "root" (which is open to debate... see below), 
you can't portably define any other location.

> 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.
 
> 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.
 
> 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.

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.

Bill Kempf