Re: [boost] Re: 31 character limit for filenames

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