Re: [boost] Filesystem on mac

From: Darin Adler (darin_at_[hidden])
Date: 2002-11-09 12:18:53

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.

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.

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.

So there are really two possible Macintosh projects:

     1) Add some Macintosh-specific functions, classes, or perhaps 
additional member functions to make dealing with both kinds of 
system-specific paths work nicely, using the POSIX implementation for 
the bulk of the library. This might be as simple as a few 
path-format-conversion functions, but providing them in the library 
could go a long way to making this integrate nicely with the various 
ways of specifying a file Mac OS X.

     2) Do a Carbon port of the library that can work in programs 
designed to work under both Mac OS 9 and Mac OS X. This would be a 
reimplementation of the library.

     -- Darin