Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk