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