I accidentally found this bug today. I was in TextEdit and hit my F11 (Exposť - Show Desktop) key by mistake when I was reaching for the Delete key. So I hit the F11 key again to bring back my work, and found out that if you hit the F11 key and then hit any qwerty keys (including the Delete key) it will affect any document, or even text input areas in a web browser.

I tested this in TextEdit, Safari, Adium, and Word on 10.5 and 10.4. So if you use F11, be careful not to press any qwerty keys while in that mode.

Those who manage large installed bases of Macs need to maintain one or more local administrative accounts on the machines, for remote administration, maintenance or troubleshooting. But, it can be undesirable to list an obvious administrator account in the Loginwindow; that same account hangs in the Fast User Switching menu, and in the Accounts Preference Pane. What to do?

Much experimentation, and some lucky finds on the Internet, have turned up the configuration to hide a user account on 10.5, and in later versions of 10.4.

In early versions of Tiger, it was easy to hide an administrator account. As per this hint, adding the array HiddenUsersList to com.apple.loginwindow with the account or accounts to be hidden was enough. But, with Leopard, this is no longer sufficient. Accounts can be hidden well enough using a HiddenUsersList entry, but the login window and Fast User Switching menu will contain an entry for "Other...," advertising the fact that one or more hidden user accounts is lingering on the system. How to get around this?

Recently I re-intalled Tiger from scratch on my old iBook G3. I let Apple's Software Update download all the relevant updates, and after the necessary restarts, I tried to mount a disk image. To my surprise, both the Finder and the Disk utility came up with an error (0xe00002c9) and refused to mount the disk image. I tried other disk images with the same result.

After some googling and searching in the Apple support forums, I came up with the following remedy: you need to manually download and install the latest Security Update (009 as of this writing) and then restart (naturally). I can only guess that this is an issue of a corrupt download from Software Update, since this security update was already installed automatically.

[robg adds: You can find the Security Update on Apple's Support Downloads page. This doesn't seem to be a universal problem (or else there would have been a major uproar about it), but there are quite a few matches to a Google query on the error code -- so hopefully this fix helps someone else out of a jam.]

I've recently discovered the NTFS-3G/MacFuse plugin that allows you to both read and write to NTFS disks. This was a great joy, as I was able to use it along with this hint to resize and restore a big windows partition.

However, as others have found, it is not possible to select your NTFS Windows partition as a startup disk. One workaround is to simply make the partition non-writable, as described in this hint, but that defeats the purpose.

Below is an AppleScript cobbled together from bits and pieces on the internet that works around the problem. Note that you have to change the first two lines to match your system.

When you use Disk Utility to create a new disk image, it defaults (at least in 10.5) to setting the Volume Format to 'Mac OS Extended (Journaled).' Normally, this isn't an issue, and it's the best setting to use. However, if you're creating a small disk image -- perhaps a 10MB encrypted image to hold your financial records -- it can be a problem. That's because the journaling information takes up about 8MB on the disk image. Add in the space lost when formatting, and you wind up with only 1.7MB of usable space.

So if you really need at least 10MB of usable space, create a 20MB disk image instead. Alternatively, you can change the Volume Format to 'Mac OS Extended,' and this will disable journaling on that image. Of the two choices, I've chosen to go with larger images with journaling enabled for those times I need a smaller disk image.

MacFuse and NTFS-3G (blog) is a great combination for those needing to have read-write access to NTFS-formatted volumes from Mac OS X. For example, with a Boot Camp Windows XP or Vista drive. Of course, this drive should also be selectable from the Startup Disk preference pane in System Preferences, as indeed happens with Apple's built-in (but still read-only) NTFS driver.

But sadly, as of now, the only way to have the Boot Camp volume show up in the Startup Disk System Preferences panel with NTFS-3G installed and active is to have it mounted by Apple's integrated NTFS driver. (NTFS-3G can still mount other available NTFS volumes read-write, of course: indeed, this hint is useful in such cases. Otherwise, one shouldn't really need NTFS-3G, or should use it with the current restriction of no Startup Disk integration). To do so, open a Terminal window and do this:

$ cd /Volumes/NameOfYourBootCampDrive
$ sudo pico .ntfs-readonly

Then save the file with the usual Control-O, Enter, Control-X. Finally, unmount and remount (with Disk Utility) your Boot Camp partition. This creates an (invisible from OS X) .ntfs-readonly file at the root of your Boot Camp volume, thus telling NTFS-3G to bypass this volume and let it be mounted by Apple's read-only driver. Of course, you will have read-only access to the Boot Camp volume, but it will still show up in Startup Disk.

Let's hope they'll eventually fix this in better ways (see full read-write integration between NTFS-3G and Startup Disk)...

While installing the 10.4.11 Server and subsequent 10.4.11 security patch, I had to wait a very long time (over an hour) while the Installer was configuring the install. I peeked in on the Installer process (using lsof and Activity monitor's 'Open files and ports' feature), and found that it was searching through every directory on all mounted drives on the machine for files to update.

Our boot volume is completely separate from our multi-terabyte data storage, so this is completely unnecessary and a complete waste of time, as there are no files on the data volumes to update. On the next three servers I updated, I unmounted all data drives before installing, and the installation of both updates took just a few minutes each.

I don't recall this being an issue in past updates, but apparently, Apple wants to make sure that they don't leave any unpatched files behind. So to speed system updates, unmount your data volumes prior to installation.

[robg adds: This may only be an issue for those with huge data drives, or perhaps only with OS X Server. I haven't noticed any lengthy slowdowns on my machine, but I'll take a look at the activity the next time I install an update.]

As noted in this earlier hint, requiring authentication to unlock the computer from screen saver, or to wake it from sleep, can be done by the currently logged-in user or any user who is a member of the local admin group (any local administrator). It is possible to change this behavior to suit your needs. First, here's how Mac OS X determines if it should ask for authentication when waking or exiting screen saver and which users it authorizes to do so.

If the Security System Preference panel's Require Password to Wake box is checked, the askForPassword key is written with numeric value of 1 in the com.apple.screensaver.[ID].plist preferences file, which is stored in ~/Library/Preferences/ByHost. As with other ByHost items, the [ID] is the Ethernet address of the primary ethernet port (en0); the ID is simply used as an identifier.

With this preference set, the loginwindow process now requires that the system.login.screensaver authorization right be satisfied. By default, satisfying that right requires that the rule authenticate-session-owner-or-admin be true. These rights and rules are part of the authorization system employed by Mac OS X. The system maintains a list of rights and rules in the /etc/authorization file, which defines which users or groups are authorized to perform specific tasks.

You can change the wake/exit screen saver authorization right by following these steps.

I've been having a problem frequently in Leopard that I only occasionally had in Tiger, which is a login hanging when trying to logout after the Finder and Dock have closed. This leaves you with no apparent way to switch to other logged in users to at least log them out cleanly before restarting. Sometimes, the logout hangs before the Dock has gone, and it is a simple matter of clicking on the Finder icon to get your desktop back.

I found that a way of escaping from this trap is to simply employ the known hint of pressing the Option key plus a hardware key to go directly to the related System Preferences panel. This will summon up System Preferences and give you your menu bar back, from where you can then switch to another user account. Closing System Preferences will make the menu bar go away, but you can also bring it back again.