Recent correspondents wrote:
>> They don't require FSSpecs.>> I could be wrong, but I don't think anybody here really needs this > much protection from an FSSpec.
With FSSpecs, as contrasted with FSRefs and CFURLRefs:
[1] You can't create a file with name >32 characters.
[2] You can't create a file with Unicode characters in name.
[3] You can open [see note 1] and read a file whose name is
problematic as in #1 or #2, but theSpec.name is not the original one.
Apple deliberately encodes the nodeID in the altered name (for example
"VeryVeryVeryLongLongLong#5DA4C0" or "???#5DF338.txt"). Saving [note
2] such files works OK as long as the .name field is left untouched
and the original file has not been moved or renamed. Attempts to save
'companion' files (by modifying .name) tend to give files on disk with
bizarre names.
[4] There are mysterious bugs when name contains certain 'high-bit'
MacRoman characters such as pi (option-p). You can open such a file,
but theSpec.name contains garbled characters. Saving the file, even
with no change to theSpec.name, gives a disk file whose name is garbled.
[5] Most of the relevant API, including the essential FSMakeFSSpec()
has been deprecated by Apple since 10.4 and could be removed in any
future OS X release.
Note 1: the FSSpec can be obtained with files$( _FSSpecOpen, "", "",
theSpec ), and the file opened for input with open "I", 1, @theSpec.
Note 2: open "O", 1, @theSpec
Deprecation by Apple may be less serious than it seems. Some FSSpec
API is still not deprecated as of 10.6, for example
GetGraphicsImporterForFile(), and cannot be removed until 10.7 at the
earliest. It wouldn't make sense for Apple to remove FSMakeFSSpec()
etc while keeping GetGraphicsImporterForFile(). AFAIK, Apple has never
withdrawn any deprecated Carbon API in OS X. FSSpecs are probably safe
for the life of Carbon.
Robert P.