Re: [boost] Review Request: Filesystem Library

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-08-04 19:42:27

At 10:29 PM 8/3/2002, Alex Rosenberg wrote:

 >on 8/3/02 12:12 PM, Beman Dawes at bdawes_at_[hidden] wrote:
 >
 >> The only thing that changes from system to system is the
 >"system_specific"
 >> path constructor.  Even for cross-platform compilation, that would seem 

 >be
 >> better handled by macros rather than burdening all users with something
 >> needed only by a tiny percentage of users.

 >What if I want to parse POSIX and Windows and Mac OS paths all on the 
same
 >host (which may or may not be the same as any of those)?
 >
 >The portable generic format used doesn't support characters that are 
valid
 >for some of those filesystems. '/' should be legal for FAT32, NTFS, etc,
 >right? Both it and '\0' are for HFS+.

Uh, both Microsoft's docs and an actual probe program say that '/' is not 
legal in an NTFS filename. It is, along with '\', a separator character on 
that system.  I don't know about the other systems, but it hardly matters; 
names with embedded '/' characters won't be portable.

The point of the portable generic format isn't to be able to represent 
every path that is valid on some operating system somewhere, rather it 
allows paths to be represented only when they follow the grammar.  Since 
the end use is use a C string representation of the path as an argument to 
some operating system function, it would be counter productive to allow a 
'\0', since this isn't allowed in the middle of a C string.

 >As noted in the code, there are some artifacts in path, one of which
 >appears
 >to be an intent to differentiate files and directories. As it stands, a
 >path
 >ending with '/' results in a throw. I'd think it would simply result in 
the
 >path tagging itself speculatively as a directory.

Any differentiation between files and directories in the path code is 
residue from a prior failed design.  It just didn't work to try to keep 
track of which the path was supposed to represent.

It might be OK to allow a trailing '/' in input, but I'd want to do an 
analysis of the pros and cons first.  As far as the actual internal rep is 
concerned, it would have to be stripped off since operating systems take a 
dim view of added characters.

--Beman