Re: Design for a file system library

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