Re: [boost] Review Request: Filesystem Library

From: Chuck Allison (cda_at_[hidden])
Date: 2002-08-04 20:03:09

The only place I've seen difficulty with '/' in file names is in the command
line in an MS-DOS shell (and in the old days we could even change '\' to '/'
with the SWITCHAR INT20 service). I still routinely use makefiles with '/'
targets under Windows XP. Where does it say that the filesystem doesn't like
'/', so I can get up-to-date?

----- Original Message -----
From: "Beman Dawes" <bdawes_at_[hidden]>
To: <boost_at_[hidden]>; <boost_at_[hidden]>
Sent: Sunday, August 04, 2002 6:42 PM
Subject: Re: [boost] Review Request: Filesystem Library

> 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
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>