Re: [boost] Filesystem on mac

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;

Should output:

     a/b a:b
     a/b a:b

 >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 
required.

 >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.

--Beman