A Weird Bug

Damn thing still won't appear, ill just have to put it down to a weird bug. [sic]
 - iPod forum poster

Applications should support ease of interoperation with other operating systems and Internet services by saving files with file name extensions.
 - Apple ADC File Name Extension Guidelines

The Times Online have a new audio book promotion. They'll have a free title available each week for the next four weeks. The downloads are free.

This week's free download is Lemony Snicket, A Bad Beginning (A Series of Unfortunate Events) narrated by Tim Curry. It's a great deal (it's free) and it's perfect for the iPod...

Audio books take a while to listen to. Being full books it's not always probable to finish one at a single sitting. It becomes necessary to bookmark one's files so one can go back to them again and pick up where one left off.

The key is supposedly changing the default file extension 'm4a' to 'm4b' so using bookmarks becomes possible and so the iPod sees the files as books and lists them in a more appropriate location.

Ironically this system works admirably with iTunes and the iPod on Windows XP but not on the glorious Apple OS X operating system.

There is an incredibly easy workaround for Apple users but the main concern will remain: what price are customers of Apple supposed to pay for their supposed superior user friendliness?

And as so often before, when a 'quirk' rears its head in the futuristic world of Apple's reincarnation of NeXTSTEP, old MacOS and the Maccies lurk around the corner.

Cross Platform Interoperability?

File extensions are Apple's way - or so they say - of enhancing the user experience and extending cross platform interoperability to the maximum. Would that it be so.

In December 2001 a now infamous (and withdrawn) technical note reached Apple developers. The hastily written note encouraged legacy Mac developers to drop their obsession with MacOS creator codes and file types and enthusiastically opt in for the new file extension system. Later versions of OS X allowed users and developers both to turn off visibility of file extensions.

[The technical note led to a shameless protest by John 'spatial Finder' Siracusa to have Apple retract their position, and diehard Maccies on the protest list even went as far as threatening to migrate to Windows if the technical note and official position were not retracted. Ed.]

Keeping the file extensions around meant that copying files to another system would work as these other systems would intuitively recognise accepted extensions for known file types.

Which is great - except that at the end of the day it's the Apple user and not the Windows user who gets left out.

POSIX Compliance?

Officially file extensions are supposed to override every other clue to association in the system as creator codes and file types are pure legacy and no more. They are no longer an official part of the file system makeup - supposedly.

But as reported elsewhere at this site, it is the creator code and file type which actually override everything else - and Apple provide no means for users to clear these fields.

The creator code and file type are both four byte fields stored in the volume control block of a hard drive [sic]. Whilst Apple purport to be POSIX compliant with their OS X, their file system continues to give them and their users trouble.

Skipping the obvious reflection that data destined for a single (wobbly) app such as Finder has no bloody business being in a volume control block in the first place, one nonetheless sees that POSIX support of Unix inodes through archaic HFS CNIDs cannot avoid being an issue.

Apple reserve all lower case creator codes and file types; anything else is free for any third party vendor to use. The system is however wrought with hopelessly untenable limitations - creator codes and file types are supposed to be unique across the board and Apple have previously maintained a database with all registered codes and types.

Considering there are only so many 'lexical' variants available, it's easy to see how few unique software products can be provided for Macintosh computers before the system blows sky wide. Luckily these creator codes and file types are no longer in official use.

But Apple still use them, and they still use them in their top of the line products, including the software packaged with OS X - and including iTunes.

The 'screen dump' facility on OS X which places PDF images in the Desktop folder puts codes and types in images. iTunes uses the curious 'hook' creator code. [What exactly do Apple have in mind with that? Ed.]

Fixing It

In addition to the three ACP tools and utilities Clearff clearff and FileInfo, the free FileType is available. FileType is a Carbon app that also runs under MacOS. It's 634668 bytes on the download (expanding to about two megabytes) and it will let you modify your creator codes and file types to known variants.

But as per usual if you can do it from simple apps you can often do it from your Unix command line. The key here is Unix doesn't know anything about HFS and its creator codes and file types. So do as follows.

1. cp <bad file> any_temporary_file_name
2. mv any_temporary_file_name <bad file>

Note you must move the file, not copy it, in the second step. Apple support Unix inodes through their HFS CNID system. Whilst Unix has nothing of the sort, HFS has Finder flags embedded in your volume structures, meaning a straight Unix copy will not interfere with this control data. Moving a file will however replace the CNID of the original with that of the copy.

See Also
Control Your Pod
iPod Therefore iPay