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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-10 11:18:34

At 07:04 AM 3/8/2002, Peter Dimov wrote:

 >From: "bill_kempf" <williamkempf_at_[hidden]>
 >> > 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.
 >
 >The problem is simply that there is no such thing as a 'root' directory 
(in
 >a portable world.) Under Windows, you can use \\192.168.0.1\sharename and
 >access the whole Internet if you like.

The way that the current standard treats filenames is unlikely to 
change.  It is unspecified if any particular filename (like 
\\192.168.0.1\sharename) will work as hoped, or result in an error.  It 
will probably work on some systems, but not on others.  Even a name as 
apparently simple as "my_file.txt" may fail on a system which requires 
uppercase names or doesn't accept "." in a filename.

We have to follow the same practice with a filesystem library, if we want a 
library that is widely portable (beyond just Windows and POSIX) and 
suitable for standardization.  For example, we can't really specify if it 
is possible to iterate over a directory named 
"\\192.168.0.1\sharename".  It would be viewed as overspecification to try 
to nail down naming standards to the point of being able ahead of time to 
say what is valid and what isn't.

--Beman