Long files names truncated?: a follow-up

Many readers replied to yesterday's item about long file names being truncated, especially with hexadecimal text substituted for the deleted portion of the name. Some of the replies overlap in the information they provide, but they all shed some unique light on this matter. Here are the highlights:

Wil Doane explains: "The #hex number is the short form of a filename returned to an app which doesn't support looooooong filenames. The hex number itself is the inode number of the file, a UNIX concept, guaranteed to be unique for each file."

Roderick Mann writes: "Filenames of the form 'This_text_file_has_a_#16F3B.txt' are what the Mac OS 9 Finder displays when a file has a name too long to display. The number is the hex representation of the file ID, which is unique on a volume, and so the truncated name is guaranteed to be unique. I suspect that good apps, using the Mac OS 9 File Manager APIs, are creating the file with the actual filename, and it's just the Finder that's displaying it wrong. However, if the truncated file is displayed in Mac OS X, then it's something else.

Mark Bogdanoff adds: "Names are not necessarily truncated. For example, Zombie can write long file names, even in Mac OS 9 though the Mac OS 9 Finder cannot read the file names properly nor can most Mac OS 9 and therefore Carbon applications. HFS has allowed long file names even in Mac OS 8.1 though there was no application to display them."

A developer gives a more technical perspective: "I am positive this is due to the developer using FSSpecs to references files instead of the new FSRef. FSSpecs only support 31 char file names and may also barf on UFS disks."

Another developer confirms: "This behavior is actually described by Apple. The HFS file system is capable of very long file names. When such a file name is presented to an application using the Navigation Services interface, returning a FSSpec (File System Spec), the name will be encoded in this fashion. The element after the # is actually the "vnode" for the file. The encoding is designed to be two way, so that most of the time references to the file will work properly from Classic or Carbon applications. The new HFS function calls use FSRefs to refer to files, and they can have the full size file name. The FSRef can be used in Mac OS 8.1 or later if they are supported by the file system."

Jason Miller pointed us to this ResExcellence page that covers this general issue. It too states that this hexadecimal text should only appear in OS 9. Here's an excerpt from a quote by Carsten Klapp: "The strange letters at the end of truncated long filenames from Mac OS X correspond to the file's or folder's reference number in the directory, converted to hexadecimal so that it uses up fewer filename characters. This value was chosen to avoid any possibility of a duplicate filename resulting from truncating the long name."

Finally. Al (of Ask Al fame) notes: "Basically, the problem is not specific to Carbon, rather it's a lack of additional fine-tuning that has to be done to a Mac OS 9 app that has been Carbonized. This is not entirely dissimilar to the Carbonized app performance fine-tuning that Steve referred to last week in his fireside chat." See this Ask Al article for more info.

To be clear, the original report described this truncating taking place in OS X with Carbonized apps, not just in OS 9. To test this, we created a text document with over 40 characters in its name. We opened it in TextEdit (a Cocoa application) and the name was retained intact. We then tried to open it with AppleWorks 6.1 (Preview for OS X version). It succeeded but truncated the name using hexadecimal characters, as the original item indicated would occur.