RE: [boost] Re: Design for a file system library

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-03-07 16:02:10

From: bill_kempf [mailto:williamkempf_at_[hidden]]
> 
> --- In boost_at_y..., "dylan_nicholson" <dylan_nicholson_at_y...> wrote:
> > 
> 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.

The problem with this choice is that "Desktop" is not the root of anything.
It is -- in a most profound paradox -- a directory in the current user's
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.

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

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

I'm not sure I follow what you mean here.  How does "top-level root" compare
to "/" in a Posix filesystem?

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

Let's not forget that determining a pathname by manipulating its various
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 relative
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 naming
schemes appropriate to the filesystem in question, then it will be of no
help to those developers.

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 exists,
then the filesystem library had better be able to handle UNC pathnames or it
will be of no use.

Rob
Susquehanna International Group, LLP
http://www.sig.com