Rixstep
 About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Learning Curve

OS X Haunts

Another installment of another never-ending story.


Get It

Try It

A recent posting at Mac OS X Hints deserves attention.

Fix MP3 files that iTunes thinks are QuickTime movies
http://www.macosxhints.com/article.php?story=20061030130022224


Do you have a problem where iTunes thinks that some MP3 audio files are QuickTime movie files? If so, such a file will still play just fine in iTunes, but iTunes will not sync it to an iPod, nor share it with other networked computers running iTunes.


If you don't immediately see what the issue is, you'll have to scroll past all the ambitiously helpful followup posts to see it.

The problem is due to the type/creator codes, and for me it happens when I've saved an MP3 file from Safari through the Quicktime plugin that Safari uses to preview audio files.

And then:

Yes, just strip the TYPE and CREATOR metadata and iTunes will now think it's an mp3 file. Also, you will now be able to play the file through Airport.

Observations

This proves a number of things.

  • The issue and the solution both have been known for years.
  • Finder info in volume control blocks, as resource forks, is dangerous.
  • Apple are truly hypocritical here, stubbornly claiming extensions get precedence when they do not and never have.
  • This is info the user cannot see and normally cannot control.
  • Too many dumb apps write codes and types. This can often be Apple themselves (Mail et al) but it's also other vendors such as Mozilla (Camino) who despite being taken to task insist in defining DMGs as 'anonymous binary' files - meaning they won't open on a double-click. (Naturally they would if they had no code and type cruft at all - that's the idea.)
  • It's far easier for a user to change an extension that said user can see than change two mysterious four byte fields said user normally cannot see.
  • Despite this being a general issue, there are dedicated apps available. (After all, this is an Apple platform.)
  • The work put into the icon at right is more than the work that goes into designing and writing an application people really need. The package itself is a freaking mess.
  • It's 260 KB to download and all it does is the following.

    MacOS.SetCreatorAndType(track[0], 'hook', 'MPG3')

  • Note that even the above line (embedded in 500 KB of code and trash on disk) is overkill, for all you really need to do is clear the fields. And if that's all you want to do (and that's all you should ever want to do) then all you have to do is drop the misbehaving files on an unassuming app such as this.

    And it's done.

  • After all these years the Maccie fanboys still haven't learned - and many of them date back to the beige box days and they still don't know better.

Facts

As has often been said, if OS X is found screwing up you'll find the 'beige box technology' behind the screw-up. Creator codes and file types are not needed to make OS X applications work and no other platform uses them. All they're good for is keeping file extensions independent of file editors. But there are a number of caveats.

You can't easily change them on your own; and once they're set it's difficult to get rid of them. And any number of apps you trust are writing them all the time.

No Apple app needs them. iTunes certainly doesn't need them. TextEdit doesn't need them for text files but Apple Mail writes them anyway. DMGs certainly don't need them and yet Camino insist on putting the wrong code and type in them.

And so forth. But it goes much further - amongst other places, it goes into your iPod™.

FileInfo

Creator codes and file types are not all that's hidden in your file system volume control block. HFS catalog info contains a slew of deprecated and still relevant flags which can (and have successfully) wreaked havoc on most OS X systems.

You can see these other flags in the illustration to the right. Even though this has squat to do with Unix, it's still there and interfering with your system.

Perhaps the most notorious of these flags is 'kIsInvisible'. It is this flag and this flag alone which makes it impossible (through Apple's Finder) to see one's song collection on an iPod and copy it back to the hard drive.

The flag's no accident: it's there because Apple don't want you to be able to copy your songs back to your hard drive. Even if you've already paid for them.

Applications like MP3Rescue won't help you here. It's basically the same type of code you need, but that would be too much to hope for.

Half a meg on your disk and it can't remove kIsInvisible.

Another Way

Of course you can do most of this yourself with no further investment. Just download the ADC tools and look up SetFile.

% /Developer/Tools/SetFile
Usage: SetFile [option...] file...
    -a attributes     # attributes (lowercase = 0, uppercase = 1)*
    -c creator        # file creator
    -d date           # creation date (mm/dd/[yy]yy [hh:mm[:ss] [AM | PM]])*
    -m date           # modification date (mm/dd/[yy]yy [hh:mm[:ss] [AM | PM]])*
    -t type           # file type

    Note: The following attributes may be used with the -a option:
        A   Alias file
        B   Bundle
        C   Custom icon*
        D   Desktop*
        E   Hidden extension*
        I   Inited*
        M   Shared (can run multiple times)
        N   No INIT resources
        L   Locked
        S   System (name locked)
        T   Stationary
        V   Invisible*

    Note: Items marked with an asterisk (*) are allowed with folders
    Note: Period (.) represents the current date and time.
    Note: [yy]yy < 100 assumes 21th century, e.g. 20yy

Note that as far as 'file browsing' goes this is relevant only for Apple's Finder: any other app helping you browse your file system will be unaffected. But when it comes to 'shell operations' anything goes.


The Oompa Loompa exploit came disguised as 'latestpics.tgz'. Tracker stopped it - but did you have Tracker?

And don't think that just because you've not yet seen 'Dog of Bride of Son of Oompa Loompa' that there's nothing out there - that 'Oompa hole' is still wide open.

Summing 2 + 2

  • It's easier to change a file extension you see than a creator code and a file type that you don't.
  • It's only possible to trust a system if it always and only opens files according to their extensions.
  • Apple technology is currently a mishmash. Codes, types, and file extensions are used chaotically.
  • The typical user gets into a frightful state because nothing works as expected.
  • Said user then submits a post to Mac OS X Hints.

See Also
Tracker: Don't Chance It
FileInfo: Control Your Pod
Learning Curve: iPod Therefore iPay

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.