When Tiger's iChat has added a feature to display the current iTunes track in your status message, it was pretty cool.

But hey, the default format of the string is pretty boring!

Here's how you can change the currently playing track status in Tiger's iChat in four easy steps:

1. Quit iChat.
2. In Terminal:
   defaults write com.apple.iChatAgent iTunesMessageFormat -string 'iTunes: %Track'
3. In Terminal again:
   killall iChatAgent
4. Launch iChat and re-choose "Current iTunes Track" menu item. Bingo!

Now for the format of the iTunes string you may want to use. In the example above, replace the format string with anything you like. Words preceeded with the % sign will be treated as meta-variables that will be expanded. Currently, the following ones are known:
Album
Genre
Year
Artist
Track
URL


There's also DisplayString and PlayerState, but they are not too meaningful. ;)

So, let me give you some examples. Let's say you play a track by Spice Girls (hello Cabel! ;), called "Mama". Here's what different format strings will give you:

iTunes: %Track - "iTunes: Mama"

%Track (%Year) - "Mama (1997)"

Argh, %Artist is playing %Track!!! - "Argh, Spice Girls is playing Mama!!!"

Well, you get the idea, right? =)

I'm looking for testers for upcoming versions of Silk, Menu Master, Labels X, and FontCard. If you want to be a tester for any of those haxies (and only those haxies) either post your full name (first and last) here along with your email address or email said information to rosyna at this company dot com along with the name(s) of the product(s) you want to test. If you are going to make a comment here with said information and don't want your email address to be available to the public, then just fill out the URL field and your email address will be hidden to everyone else.

Please note that it may be a while before some of these go into testing and once they do you'll likely get a bunch of emails about new versions in a short amount of time. And for the love of Pete, if you ask to be on any of the above product's lists, then submit feedback when you get a beta version. Even if that feedback is just "Works fine here, cowboy."

We will not sell your email addresses or names. We also do not store the email addresses on any PCs at all so there is no chance of them being compromised. And this is only a request for the above products only.

This is a rant I've wanted to write for an extremely long time. However, I prefer to let my anger/annoyance with some topics sit in the stew that is my soul and slowly boil until it is like you dropped a tea bag into a cup of very hot water housed in a smooth glass container that you just stuck in the microwave for 10 minutes. Yes, doing that will cause the water to spontaneously explode, leaving horrible burn marks all over your face (just be glad it wasn't maple syrup or something else that could stick to human flesh).

Update: Despite what Apple's Knowledge Base Article says, Repair Permissions does not repair permissions on any third party software (or any Apple software outside of the Base System). I just checked this by changing the permissions on FontAgent Pro and then repairing permissions. The permissions were not set to their correct values. This makes repairing permissions even more useless as it can't be used for any non-apple software. It also explains why installing CHUD or iPhoto from iLife '05 would cause the incorrect warnings to appear.

Now that that pleasantness is over with, the real issue I have is all these websites that suggest repairing permissions will actually fix/prevent problems. Even worse is when otherwise intelligent people are poised with a Mac OS X related troubleshooting problem and immediately suggest the user repair permissions. Repairing permissions won't fix your problem. As Jason Harris said (and I am paraphrasing), "Repairing permissions is zapping the PRAM for the twenty-first century". I couldn't agree more. Both are equally futile attempts to fix a completely unrelated problem. In other words, 99% of the time, neither will fix nor prevent any problem. Especially not the problems they are recommended for. Covering yourself in vaseline and rolling around naked in the dirt and repairing permissions are just as likely to fix your Mac OS X problem. People swear by repairing permissions as often as they save files and present as proof the fact they don't have any problems. That's rather specious reasoning. As with everything in life, The Simpsons has covered this topic well. Yes, I've shamelessly copied this text verbatim.

Homer: Not a bear in sight. The Bear Patrol must be working like a charm.

Lisa: That's specious reasoning, Dad.

Homer: Thank you, dear.

Lisa: By your logic I could claim that this rock keeps tigers away.

Homer: Oh, how does it work?

Lisa: It doesn't work.

Homer: Uh-huh.

Lisa: It's just a stupid rock.

Homer: Uh-huh.

Lisa: But I don't see any tigers around, do you?

[Homer thinks of this, then pulls out some money]

Homer: Lisa, I want to buy your rock.

[Lisa refuses at first, then takes the exchange]

Please ignore the fact that they're talking about tigers and Mac OS X version 10.4 just happens to be called "Tiger". The point stands. Just because something isn't around because you do something every day does not mean it would suddenly come around when you stop doing the something every day. Some people used to smear chicken blood all over their kin to keep the devils away too.

Call Me Lucy

I guess I should explain what repairing permissions is and isn't. Repairing permissions goes through all the Package files (.pkg) in /Library/Receipts/. A receipt package is created when (and only when) you install something using Installer.app (Apple's installer). First it creates a temporary package based on all the files in the package. Then when you install, it creates the actual package that actually contains a listing of all the files you installed from that package. You can see these two steps if you open Installer.app's Log window and choose "Show everything". The package lists the paths for all the files along with the permissions Installer.app set for them when they were installed (those permissions are part of the actual package in which the files were installed from). The items in /Library/Receipts/ are basically just the shell package without any of the actual files inside. You can see the contents of these by using the lsbom utility. The usage is basically lsbom path/to/archive.bom. Like so:

lsbom /Library/Receipts/MacOSX10.4.pkg/Contents/Archive.bom

This will list all the files that were installed by the package (by absolute path, usually), their installed permissions, file size, and some other information. See the man page for lsbom for more information on the output.

Anywho, when repairing permissions, the disk utility goes through the permissions of all the files in the target volume's /Library/Receipts/ folder. Apple has a kbase article on this as well. In order for the "repair permissions" or "verify permissions" button to show up, the target volume must have a version of Mac OS X installed on it. Repairing permissions only works on volumes that have a /Library/Receipts/ folder. Which is only there if OS X is installed on that volume.

Based on this information (and the sheer stupidity of Installer.app) you can correctly assume that Repair Permissions won't touch any files in any of the user's home folders since Installer.app can't target user folders specifically, only any folder or a specific path, and there are no packages in ~/Library/Receipts/. The only way it'd ever touch any files in a user's folder is if you installed something that let you explicity select a folder to install in (there are very few of those, none are available from Apple publically) and you chose a folder inside your user's folder. The receipt would still be installed in /Library/Receipts/ and it would only affect the user that installed it. It also won't fix permissions for any files that were created during the normal (or abnormal) use of OS X. This means it won't touch any cache files, database files, swap files, or settings files not created by the installer. If a file isn't listed in a receipt, it doesn't exist to the repair permissions process. It's really as simple as that. And because it reads from /Library/Receipts/ on the target disk, you can boot from a Mac OS X 10.2 CD and still use it to (correctly) repair permissions on a volume with Mac OS X 10.4.6 installed on it and it will set the permissions to the ones that 10.4.6 requires. There is no need for you to boot off a volume in order to fix its permissions.

A Bit of History

Does anyone actually remember when Apple first offered the ability to repair permissions and why it was needed? I do. Apple introduced the Repair Privileges Utility as a download for machines running Mac OS X 10.1.5. This was back in the long ago time when Macs would still boot Mac OS 9 and the default environment for a lot of Mac users was still Mac OS 9. Mac OS 9 didn't care about permissions at all. Mac OS 9 was Mac OS X's worst enemy in this area. If you booted into Mac OS 9 and ran some common applications, compressed and decompressed files, moved or renamed files, or (worse) ran a disk utility like Norton, they could completely destroy the permissions for many files that OS X needed to boot or run correctly. Since this was a relatively common occurrence and a huge support issue, Apple introduced the Repair Privileges Utility. When Mac OS X version 10.2 "Jaguar" came around, Apple rolled it into Disk Utility where it belonged. But by this time it wasn't needed nearly as much since many new Macs couldn't even boot Mac OS 9 thus rendering the fear of bad disk utilities that didn't pay attention to the rules set out by the HFS+ Technote ruining the ability to run OS X completely moot. Just because HFS+ didn't use the features when you wrote the disk utility doesn't mean it won't in the future (and the future is now, excluding named forks). None of this applies to using Classic as Classic lives in a mostly happy sandbox with just a trace amount of urine (which is more than I can say for my spacesuit).

The other number one cause of permissions going wonky were 3rd party installers that asked for root on OS X and changed permissions on some folders that were in the path to the destination. I know that MindVision and Allume (Courtney Cox-Arquette) have long since updated their installers to prevent this kind of weirdness (these would be the same installers that told you to quit all applications when installing software on OS X). I know there is always a chance I could be wrong about things like this so I've been running Repair Permissions after every install using these two installers just to make sure, and I haven't seen it note anything at all. So these two companies' installers are good. So this cause is also deemed completely moot.

The final minor cause for incorrect permissions is, basically, the user. I've said it before, and I'll say it again, you can't account for stupidity. People that change permissions on something because they think it might fix a problem they're having because they know more than the system but it very obviously won't fix the problem. More on this reason later.

The Ugly

Permissions won't magically go bad. They won't break suddenly. They don't suffer from bit rot. In order for permissions to change something must change them. Even with Mac OS 9, as long as you didn't modify the files, their permissions wouldn't change. For this reason, repairing permissions as a maintenance task is just a complete waste of time. Granted, it won't harm anything, but it won't help anything either. If you want to be paranoid about permissions then at least use some common sense when doing it and only run repair permissions after using an installer. I am not recommending doing it after using an installer, however.

I've only ever found two cases in which repairing permissions would actually help fix something. One is when backing up to a non-local (external) volume (like a FireWire HD, a USB 2.0 HD, or a disk from FireWire Target Disk Mode) via ditto (with the --rsrcFork option passed) or Carbon Copy Cloner. You really shouldn't use drag and drop in the finder or cp to backup OS X volumes as important metadata can get lost that way. There is one reason and one reason only I say that the use of ditto or CCC would require a repair permissions on the volume everything is being backup up to--when the volume has the "Ignore ownership on this volume" checkbox checked. Ignore Ownership on this volume should be unchecked. If it isn't, then none of the permissions will be copied over in the first place and then you have to run repair permissions to make the thing bootable. But I still don't recommend it as any files not installed by the installer won't have the permissions fixed and could be a huge security risk (especially if it is world writable file). So make sure that box is unchecked. It's checked by default on non-local volumes. Also note that if you don't uncheck that box, you will have to reinstall Application Enhancer as it is permission sensitive and if that box is checked while you're doing the copy/backup it won't have the proper permissions to run. This has come up a lot in support emails but by then it is too late to tell the user to uncheck the box. This item is preventable.

The other case when repair permissions are required is also in the user error category. But this is when installing system services using very outdated instructions that tell you to assign the wrong value to a now default OS X user. I can't blame them because I thought that I knew what I was doing. In this case repairing permissions was the fix (as long as I made the postfix uid 27). I could have easily fixed them manually, but that was a few more keystrokes and I was feeling keystroke lazy. This item is preventable.

Anecdotes are not Proof of an Antidote

Now let's see what some very silly people are saying about repairing permissions and why it is flat out wrong.

7) Repair Permissions

8) Install Mac OS X 10.x.x update

9) Repair Permissions

Ugh. This is the one that annoys me the most and the reason why I wanted to write this rant. When 10.3.9 came out, I saw this all over on just about every single Mac related website. This really boils my blood. First we have the completely bizarre suggesting of repairing permissions before installing an update. Useless. When you install a system update (or pretty much any updater using Installer.app) you are asked for your password. This makes the installer process run as root. Wrong permissions, bad permissions, no permissions, it doesn't matter. root is god. It doesn't care about what some small little file has as its permissions. It will just ignore them completely. *chortles demonically* You can't stop root. Repairing permissions won't increase the chances of the install succeeding (nor will it decrease the changes). Point nine is equally as baffling. As the installer is installing/updating files it also reset the permissions to those that will be in the receipt that the repair permissions process reads from. You just installed these files, they are going to have the correct permissions.

I was having problems with permissions with files on the scratch disk so I repaired permissions on it and it fixed everything.

This is a paraphrase of something someone actually said to me. It is real. It is a lie. I can say that without even knowing how this person handles problems (even though I do know how he handles OS X problems). Why? He says "scratch disk". For those that have never worked with media or photoshop, scratch disks are dedicated volumes (usually separate physical disks, in this example it was another partition) that is used to store all the render files and temporary media files for a project. They are used often to increase render speed when applying compute heavy effects to files. They are separate disks so they can be read from/written to quickly without having to compete for I/O time with the boot disk. It's also good to keep them separate so if Project A needs scratch disk space, it can easily delete all the scratch space for Project B while making sure that Project B doesn't suffer by having to reimport media. Although if you do delete Project B's scratch files, you'll likely be stabbed anyways as it can take hours to rerender complicated projects (but on the upside, the people working on Project B don't really have to do any work to rerender).

Since, by definition, a scratch disk does not have an OS installed on it, there is no way he could have repaired permissions. No OS, no /Library/Receipts/ which means no repair permissions. The actual fix to his problem? Get info on the scratch disk and check "Ignore Ownership on this volume". The problem appears to be that multiple users are using that scratch disk with some of them working on the same projects. If a user named "rosyna" creates a file, its default permissions will be 0644 with owner rosyna and group rosyna, This means if user "slava" comes on and tries to write to that file, he can't since he is neither me nor a member of me. Ignoring ownership would mean that everyone can read and write whatever file they want on that volume.

iTunes kept throwing up an error saying "Cannot save library. -54". So I opened a get info window on the iTunes application and gave everyone the ability to read and write to it along with all enclosing items and the error when away. But every time I repair permissions, it keeps stupidly resetting the permissions back and the error comes back.

Same person as above. A lot more paraphrasing was done. The error is the same (Library, can't save, and -54). His actions on the iTunes application bundle are the same, and he did indeed say it fixed the problem. Not only is it a huge security risk to give everyone write access to an application, it is a lie. Yes, a -54 error is a permissions error (on file open). But note that the error said "Can't save Library". Library refers to the iTunes library. This file is located at ~/Music/iTunes/iTunes 4 Music Library. Note that it is stored in the user's home folder (that's what the ~ means). This means two things. 1) Repairing permissions won't fix the problem. 2) His problem has nothing to do whatsoever with the iTunes application. Not that it matters since an application on OS X must not write to itself. This was a huge source of problems in Mac OS 9 so resource forks that are opened automatically on application launch are opened read only on Mac OS X.

This fix for this (as I know it, I've only had the problem once) is sadly rather invasive. Delete the iTunes 4 Music Library. Reopen iTunes, choose "Import" from the "File" menu and import ~/Music/iTunes/iTunes 4 Music Library.xml. It will take a while and you will lose some data. But it will import all the files that it can find on your computer. It sadly won't re-add files that it couldn't resolve at the time iTunes last made the XML copy of your library which should have been the last time you quit iTunes successfully, the last time a change was made to the iTunes library, or the last time someone connected to your iTunes share. Your playlists will be retained although you might get duplicate copies of your smart playlists (I did of a few) and the order of some of your larger playlists might be completely screwed up.

Normally I don't say something is a lie (or call someone a liar) flat out in public (or even privately) and this wasn't a lie done for malicious purposes. It was more of a lie in the sense that this person isn't quite sure what actually was happening and likes to argue endlessly and when presented with explanations for what actually happened tries to make it seem as if the people giving the explanation are wrong (inherently and always). He changes the past ever so slightly to suit him best hoping that no one will catch on. His memory isn't that good either.

I was having this huge problem with some huge third party application and repairing permissions fixed it.

Extremely doubtful. Most of the time huge third party application is something by Microsoft, Adobe, or Macromedia. None of which use Installer.app. Which means that repairing permissions couldn't have possibly fixed any issue that only one of these applications was experiencing. For example if the permissions for /Library/ were set to 000 then all hell breaks loose. And I'm not kidding about that. Disk Utility stopped working, ShapeShifter stopped theming, and Adobe Photoshop CS 2 (9.0) showed me this on launch, without holding down any keys as startup:

How to Solve Problems and Stop Repairing Permissions

It'd really help a lot if people would stop trying to assume repairing permissions does good and actually try to find out what's causing a problem they're having. For the people willing to try, I point to the the Console (/Applications/Utilities/Console). The console has the answers you seek, young one. For just about any problem with anything, the Console log will list it for the above Library example, Photshop actually told me that it couldn't read files from the Application Support folder (which is correct). But make sure that what you're looking at actually relates to your problem. If Virex keeps crashing and you see:

May 15 15:35:09 Stability-64 kernel[0]: Limiting icmp unreach response from 314 to 250 packets per second

In the console, do not assume it has anything to do with your problem. For my postfix example above, the console clearly has the following to say:

May 16 12:39:00 Stability-64 postfix/master[487]: warning: master_wakeup_timer_event: service public/qmgr: Permission denied

May 16 12:39:05 Stability-64 postfix/master[487]: warning: master_wakeup_timer_event: service public/pickup: Permission denied

Notice how it says "Permission denied"? That means it doesn't have the correct permissions and fixing permissions will definitely fix this problem. For what it's worth, I changed all the files in /var/spool/postfix to be owned by rosyna.

In summary, repairing permissions is useless 99.9% of the time. Permissions don't magically go bad. And you should really throw out "repair permissions" as a troubleshooting step until you've exhausted all other methods of troubleshooting. Reparing permissions can only fix problems with Mac OS X system files distributed by Apple installed by Apple's Installer.app and only as long as a valid receipt is available. Even then, it should never be suggested to others as it won't help and sadly will only make you look like you know less about Mac OS X than you really do. Repairing permissions is the strategy of last resort!

I guess what I'm trying to say with all this is that if you're going to heat up water in the microwave for use in tea, put the teabag (without the metal) in the cup of water before you heat it up and keep it in there (without metal) while heating it up.

Here is the second beta of Labels X 1.7 (Tiger Compatible). I've got nothing witty to say here.

Version 1.7b2 (Thursday, Patty Mayonnaise 57th, 2005)

• Now completely ignores PowerPlant on 10.4 even if for some bizarre reason some really whacked out plugin loaded it from a framework they included. PowerPlant is not included with 10.4. Praise the lord.
• This also fixed a finder crash when changing an option in the prefpane because someone didn't check to see if it was actually available before using it. Always check for NULL.
• Now loads the external framework for images when needed. Not on application launch.
• French localization by Bernard Rey.

Version 1.7b1 (Mayizzle 57th, 2005)

• Fixed a problem with icons being chopped off on the desktop if the text was set to be to the right of the icon.
• Tiger Compatible. Uncle Approved.
• Updated to APE 1.5.
• Lovely new installer.

Get it at http://www.unsanity.net/beta/labels-x-17b2.dmg (2.10 megs)

There's a bug in Mighty Mouse 1.2 that prevents valid registrations from being accepted properly. There's a semi-public beta of Mighty Mouse 1.2.1 here. I do not guarantee that it will resolve the registration issue, since I've had conflicting reports on what the problem is. If you're affected by this issue and are adventurous enough to try a beta, please contact me to tell me whether it worked or not. You can email me at my first name (actor Priestly, mythical guy who hung out with aargonauts) at a lil' company named Unsanity, which is a dot-com.

You should log out after installing.

The beta also resolves an issue with cursor scaling not being properly applied at log in. But please remember, it's a beta - if you're not comfortable with testing, stay away!

iTunes 4.8 was just released and it seems to have support for video. Which is really weird. You can even play movies fullscreen without QuickTime Pro. Odd that Apple is including this in iTunes. Sadly it won't allow you to add AVI files even if you have a codec for the file. So much for Family Guy

Update: If you click the little artwork/player window in the lower left hand corner, the movie will open in a brand new window. Don't do this with the HD version of the Serenity trailer unless you have a really fast computer or patience.

Here is the beta for Menu Master 1.3 with Tiger support. Love it long time.

On a side note, I'm kind of sad that Adobe doesn't offer NFR's of their Suite to lowly people like me.

Version 1.3b2 (May 4nd, 2005)

• Fixed a problem when setting keys for dynamic menu items (like most items in the Finder). This change now ungroups dynamic menu items when you set new keys for them. This change means you need to change any newly visible items to have keys similar to what you just set.

Version 1.3b1 (May 3rd, 2005)

• This is a free update for registered users.
• Addressed a crash with URL Manager Pro.
• No longer confuses set hotkeys in FruitMenu or FontCard menus.
• Fixed a problem that would cause some pull down menu keys to be off by one.
• No longer sets the same hotkeys for all popup menus in an application.
• New Registration System. Registered users are able to click the Update Now button to quickly and easily update their registration. The new serial number works across users so if you have permissions to write to /Library, all users will get the new SN automatically.
• Tiger Compatible. Mother Approved.
• Spifftacular New Installer.
• Updated to APE 1.5

Get it at http://www.unsanity.net/beta/menumaster-13b2.dmg (1.35 megs)