On Mon, 16 Aug, 2004, at 11:34 pm, Miro Jurisic wrote:
Steve Ramsey <steve@lucena.com> 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 answer. 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 route... Steve