From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-03-07 09:59:26
--- In boost_at_y..., "dylan_nicholson" <dylan_nicholson_at_y...> wrote:
> --- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> >
> > 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.
> >
> Actually what is appears as (by default) "My Computer" in Explorer
> acts more sensibly as a top-level "root" (a:\, c:\ etc are under
> here).
Possibly, but I still prefer "Desktop" as this is truly the root of
the shell namespace and includes "My Computer".
> The fact that under POSIX "/" has a usuable name, but under Windows
> the equivalent concept doesn't may be an issue (it might not be
clear
> how to specify "create a directory at the root directory level",
> which is not possible under Windows).
Actually, if you use "Desktop" then the "root" is usable. You can
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 in
the way Beman described... and I still think this is the correct
design choice.
> Basically I would expect a top-level iterator on Windows to return
> a:\, c:\ etc. (but not Control Panel, Printers etc - I don't see
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 I'd
like to see them included. Yes, it's a platform specific extension,
but not one that should cause problems with portable code. I think
it important to include this, because other platforms may have
similar concepts.
> 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 filesystem.
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".
> One issue though might be where UNC pathnames fit into the Windows
> 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-name\sharename,
but
> in principle it would also be nice to iterate through '\\', which
> would return all computers in the network neighbourhood (including
> the local machine). If this was possible then it would be quite
> reasonable to have \\ returned after a:\...z:\ from the top-level
> 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, but
the proposed requirements demand a single naming scheme (though the
scheme is not specified). One benefit to the idea of using the Win32
shell namespace and "Desktop" as root is that this will give you
access to the network neighborhood, with out the need for multiple
naming schemes.
Bill Kempf