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:  You can't create a file with name >32 characters.  You can't create a file with Unicode characters in name.  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.  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.  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.