Boost logo

Boost :

From: Steve Ramsey (steve_at_[hidden])
Date: 2004-08-17 03:05:21

On Mon, 16 Aug, 2004, at 11:34 pm, Miro Jurisic wrote:
> Steve Ramsey <steve_at_[hidden]> wrote:
>> FSRefs can only refer to pre-existing file system objects - this
>> merited a
>> single sentence in a single tech note far away from the File Manager
>> documentation - which makes them bloody useless for general path
>> conversions.
> You probably want CFURL APIs for path conversions. However, you should
> explain a
> little more what you mean by path conversions, as there are some
> non-trivial and
> very subtle issues regarding HFS paths and Unicode characters. (But
> they may be
> completely irrelevant to you, which is why I ask what you mean.)

I'm not sure sure how helpful the CFURL stuff is for what I'm doing, as
I'm not sure there's an easy way to get HFS paths out of them when
running under OS X (as I hinted before, why on earth would you want an
HFS path at all under OS X, except to make the MSL happy). The path
conversion was an obscure reference to one of my failed cunning plans
to convert POSIX paths to HFS paths by having
FSPathMakeRef/FSRefMakePath do the work for me; I was toggling the
gestaltFSUsesPOSIXPathsForConversion bit in the gestaltFSAttr Gestalt
selector between calls. This fails in the general case since FSRefs
can't refer to non-existent objects, but it neatly side-steps the text
encoding issues when the object does exist. In the absence of
system-level hacks, I'm hoping this sort of path conversion isn't the

I'm now looking into re-writing certain low-level MSL source files such
as path2fss.c to use POSIX paths instead of HFS paths, as there is
precedent for Boost libraries providing alternative MSL files to
overcome certain deficiencies (boost::thread, for example). Really,
though, at this point I'm just fishing while I wait for an elegant
solution to suggest itself, where elegant is something other than
writing off the MSL for Mac development.

Here's a quick summary of what I'm dealing with: the goal is to be able
to use boost::filesystem with Metrowerks CodeWarrior and the Metrowerks
StdLib/STL implementation, MSL, on a CFM Carbon program intended to run
under OS 9 and OS X. Ideally, only a source implementation should be
necessary, and the interface files and MSL source should be off-limits
(although I'm thinking some interface files needs to be changed to be
more generic, e.g. handle-body idiom for path, or I need to throw this
restriction out and just litter the interface files with more
preprocessor conditionals and give the classes target-specific
privates). The POSIX path will not work in this scenario since the MSL
uses HFS paths (HFS paths: multi-root, colon delimiters, specify
relative paths in the reverse fashion of POSIX, often Pascal strings in
Carbon API calls, C strings in MSL calls). You can get a lot of mileage
out of a proper rewrite of fs::path::native_file_string, but for total
compliance work also needs to be done in fs::operations. Without
system-level conversions to handle all the gritty details, the key
solution here will probably be to write a heroically specialized manual
HFS<->POSIX path converter that takes into account things like multiple
roots (e.g., faking a /Volumes directory under OS 9), File Manager name
mangling, and possible weird issues with aliases and symbolic links
(mmm...cross-volume aliases). I'd _really_ like to avoid going this


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