From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-11-09 14:23:13
At 12:18 PM 11/9/2002, Darin Adler wrote:
>On Friday, November 8, 2002, at 06:04 PM, Beman Dawes wrote:
>> So no need to guess, except in the case of a system which supports
>> multiple system specific formats.
>It's a kind of funny situation.
>Mac OS X does of course have enough POSIX support that the POSIX
>implementation can be used. But this would leave a bit of a hole
>because there's a second system-specific path format on OS X; besides
>the POSIX style, there's a traditional Macintosh style that uses ":" as
>the separator rather than "/". I guess the filesystem library could
>just ignore this issue, but one that truly embraced OS X support would
>have some way of dealing with the multiple system-specific formats. In
>this case, a parser can not determine the format by inspection. In a
>POSIX path, "a:b" is a legal file name. But interpreted as a
>traditional Macintosh style path under OS X, it means what a POSIX path
>of "/a/b" would mean.
It is always hard to be sure about an O/S I have no personal experience
with, but it sounds to me as if boost::filesystem::path's system_specific
constructor and access functions should be used for Macintosh style paths,
and the generic constructor and access functions (as always) be used for
generic (ie POSIX) paths. Thus:
path p1( "a:b", system_specific );
path p2( "a/b" );
cout << p1.generic_path() << " " << p1.file_path() << endl;
cout << p2.generic_path() << " " << p2.file_path() << endl;
>The Carbon environment, for applications that work both on OS 9 and OS
>X, does not include POSIX support, and I can easily imagine people
>wanting a port of filesystem library specifically for the Carbon
>environment that is not OS X specific. That's what "Macintosh support
>for paths" would probably mean.
Yes. Hopefully the interface is unchanged, but a reimplementation would be
>There's a third issue of resources forks and non-POSIX file attributes.
>There's probably not a reasonable way to abstract these in the
>filesystem library, although it would be nice to have a library that
>can be used to successfully copy files even on systems where files have
>additional meta info beyond the file contents. This is a similar issue
>to the issue of representing privileges in a system-independent way.
That's outside the scope of the Filesystem Library. Jan Langer plans to
attack that problem through an attribute library.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk