Boost logo

Boost :

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-03-07 16:44:42

--- In boost_at_y..., "Stewart, Robert" <stewart_at_s...> wrote:
> From: bill_kempf [mailto:williamkempf_at_h...]
> >
> > --- In boost_at_y..., "dylan_nicholson" <dylan_nicholson_at_y...> wrote:
> > >
> > Possibly, but I still prefer "Desktop" as this is truly the root
> > the shell namespace and includes "My Computer".
> >
> > > The fact that under POSIX "/" has a usuable name, but under
> > > the equivalent concept doesn't may be an issue (it might not be
> > clear
> > > how to specify "create a directory at the root directory
> > > which is not possible under Windows).
> >
> > Actually, if you use "Desktop" then the "root" is usable. You
> > create files and directories there. I didn't mention this in the
> > first e-mail because it ignores the fact that there are platforms
> > (DOS, for example) where a "root" that logically collects all
> > available drives in a read-only "directory" would have to exist
> > the way Beman described... and I still think this is the correct
> > design choice.
> The problem with this choice is that "Desktop" is not the root of
> It is -- in a most profound paradox -- a directory in the current
> profile directory, which may or may not be on the local machine! It
> certainly is a subdirectory somewhere. That, in a typical end-user
> installation, means that if you navigate "Desktop" to find "My
Computer" and
> then locate the C drive, you can navigate to
> C:\Windows\Profiles\user\Desktop to get right back where you
started. That
> doesn't seem very useful.

Again, "Desktop" *IS* the root of the shell namespace. I undestand
what you mean about it also being a directory found elsewhere and
dislike this pseudo-circular concept in the Win32 architecture, but
that doesn't invalidate the fact that it *is* the root of the Win32
shell namespace.

> > > Basically I would expect a top-level iterator on Windows to
> > > a:\, c:\ etc. (but not Control Panel, Printers etc - I don't
> > how
> > > you *can* treat these concepts portably).
> >
> > You return a "name", just like you do for files/directories. Of
> > course checks for is_directory and is_file would fail for
> > these "names", but the name is still usable to programmers, so
> > like to see them included. Yes, it's a platform specific
> > but not one that should cause problems with portable code. I
> > it important to include this, because other platforms may have
> > similar concepts.
> That's interesting.
> > > On POSIX there's two
> > > choices, it returns *just* '/', or it returns /bin, /etc, /home
> > etc.
> > > etc. I prefer the former, as
> > >
> > > a) The "top-level" root has no name, it simply represents the
> > entire
> > > filesystem
> > > b) All entries under this are named components of the
> >
> > This makes the "top-level" POSIX root the exact same as the
> > proposed "top-level" root for DOS and similar systems. It's not
> > usable as a name for use in standard library I/O operations, and
is a
> > read-only "directory".
> I'm not sure I follow what you mean here. How does "top-level
root" compare
> to "/" in a Posix filesystem?

root_directory() just returns a "name" that represents the systems
root "directory". Above you claim that you want this directory
to "return" just '/', which indicates to me that '/' is the only
entry in the "directory" returned from root_directory(). This makes
it a "logical/psuedo/whatever" directory in the same sense that
a "root" directory in a DOS like system would be if we follow Beman's
suggestion. I'm not claiming to agree with this, I'm just trying to
follow the logic in the posting.
> > > One issue though might be where UNC pathnames fit into the
> > > scheme. I would probably expect to be able to iterate through
> > > everything in \\computer-name (and note you can't do this with
> > > FindFirstFile), and certainly through \\computer-
> > but
> > > in principle it would also be nice to iterate through '\\',
> > > would return all computers in the network neighbourhood
> > > the local machine). If this was possible then it would be
> > > reasonable to have \\ returned after a:\...z:\ from the top-
> > > iterator. But to be honest this functionality is not entirely
> > > trivial to implement and I'm not sure whether it belongs in a
> > generic
> > > file system iterator library. Also where do you stop - I might
> > very
> > > well want to iterate through http:// one day :o)
> >
> > UNC is an alternate naming scheme, and, correct me if I'm wrong,
> > the proposed requirements demand a single naming scheme (though
> > scheme is not specified). One benefit to the idea of using the
> > shell namespace and "Desktop" as root is that this will give you
> > access to the network neighborhood, with out the need for
> > naming schemes.
> Let's not forget that determining a pathname by manipulating its
> pieces is at least as often not about starting at root and
navigating to
> find something. Often you're given a path as the basis for making
> pathnames absolute via parameter. If that parameter is from a user
or a
> native directory selection dialog, then the name of that path may
be in any
> number of formats. If the filesystem library cannot handle various
> schemes appropriate to the filesystem in question, then it will be
of no
> help to those developers.

I didn't forget this. But I *think* the proposal is to define a
single naming mechanism. This seems to be indicated by the
discussion of URIs in the design documentation's rationale. Other
naming schemes will have to have some way to be "bound" to this
single naming scheme, of course, but that's a different issue then
the hybrid described. At least from what I understood of what was

> For example, if a developer wishes to use Windows' shell
functionality to
> display a File Open dialog so the user can locate a file, and the
user finds
> a file under a share on some host for which no mapped drive letter
> then the filesystem library had better be able to handle UNC
pathnames or it
> will be of no use.

Not exactly. You have to be able to bind the UNC to a
meaningful "name" in the proposed scheme, and the proposed library
must be able to define "names" to such locations, but the two naming
schemes don't have to be the same, nor be mixed in a hybrid system.
Of course, the proposal purposefully doesn't define the format of
the "names", and it well me be that an implementation mixes UNCs with
traditional DOS paths to accomodate all of this on Win32, making the
binding extremely simple... but it's simply an implementation detail.
Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at