Boost logo

Boost :

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
> >be
> >> better handled by macros rather than burdening all users with
> >> 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:

Boost list run by bdawes at, gregod at, cpdaniel at, john at