Re: Design for a file system library

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

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

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

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

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

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