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.
I really this older hint, on how to change the login window background by telling the system to look for the image in another location, but I want to suggest a small variation of it.
I like to constantly change my backgrounds. I have a directory with a bunch of background pictures, so I wrote a simple AppleScript which takes a random file from this directory and saves it as the picture used as the login window background. Mine is named myloginwindow.jpg, and it sits in my Public folder.
Then I saved the AppleScript as an application, and added it to the login items for my account. Now every time I log in, I see a different login background. Since I really know nothing about AppleScripting, the above is probably not ideal (please feel free to suggest improvements in the comments), but it works for me.
[robg adds: I haven't tested this one, but to make it work, you'll also have to have used the linked hint to specify a new location for the login background images.]
I had a problem with strange characters not deleting in the Trash. They looked like asian characters, or zeros and slashes, something similar to: //00]|||00. Emptying the Trash deleted the files, but not the characters. If I did a Get Info, they would disappear, but come back if I deleted more files. I found out that it was caused by a corrupt file on a FAT32 Boot Camp partition in the C:.Trashes501 folder, and was causing this issue.
I repaired the problem by booting into Windows using Parallels, and running the Check Disk Utility for Windows hard drives. (Open My Computer, right click on the 'C' drive, and click properties. Click on the tools tab, then Check Now. Make sure that there is a check in the box that says "Automatically fix file system errors." Then you will be prompted to reboot. Check Disk will run on reboot.)
Check Disk found the error in the C:.Trashes501 folder and repaired it. Now my Trash in OS X does not have the strange characters when I empty it. I haven't tried it, but I would assume that if I just booted into Windows (through Bootcamp, or Parallels or VMWare Fusion) and deleted the .Trashes folder on the "C" drive, that it would work also. If you have an external drive formatted in FAT 32, you can plug it into a Windows machine, and you should be able to do the same thing.
Reinstalling Leopard, fdsk, and command line deleting of the Trash did not solve the problem, but this did.
I noticed a possible bug when two users are logged in at the same time with the "fast user switch" option.
Assume I have two users, both with admin privileges -- user A and user B -- and both are logged in. Currently user A is working. The security preferences are set to ask for password if the screensaver or screen dimming goes on.
If you let the screensaver start, once you resume work, you get the login window asking for password. It will show the username of A and ask for the password, as that was the user working. However, if you change the username to user B and use that password, that will unlock the computer, but you will be logged in as A. So you can get access to all of user A's system by logging in as user B.
[robg adds: I tested this, and it's definitely true. However, given that both accounts are admin accounts, I'm not sure if it's a bug or simply unexpected behavior. As an admin user, user B could change user A's password at any time they wished, and then login to the account. I also tried unlocking the screensaver as a non-admin user, and thankfully, that did not work.
Update: Please read the comments for more details on how/why this works, and that it is indeed a feature and not a bug. While I understand that admins need control over the computer, it still doesn't seem quite right to me that a locked screen for a given account can be unlocked by any other admin account. I'm not sure what the right behavior might be, though. Perhaps asking the user to provide the user/pass of the logged-in account, or offering the option to start a new session via fast user switching?]
For those who use Apple's wireless mouse or keyboard, you might find the appearance of a flashing Bluetooth menu bar item bothersome when the batteries in your device run low. Disabling the item from the menu bar by command-clicking and dragging is only a temporary solution, as it will continuously reappear until you have recharged or replaced your batteries.
Since there is no option to prevent this warning from appearing, the following hint may be useful for those who do not use and will never need the Bluetooth menu bar item: Simply move or rename the Bluetooth.menu file from the /System » Library » CoreServices » MenuExtras folder.
[robg adds: In general, I do not advocate moving or renaming system files. However, as a user of both the wireless mouse and keyboard, the flashing warning is annoying -- as is the fact that it will automatically add itself back to the menu bar even if you remove it. If you try this hint, I strongly suggest putting the menu extra back before running any Apple Software Updates. If anyone has a better solution, please post it in the comments.]
It is very difficult to create a disk partition of the exact same size as an existing partition of another disk using Apple's Disk Utility. Whenever I try this, I always find the size of the partition created by Disk Utility is slightly different from the partition I'm trying to clone. Here's a way using the command line that allows you to get the size exactly right.
The standard warning applies: Be very careful. This will wipe the entire disk that you are repartitioning. One small typo could result in the wrong disk being wiped!
In the Spotlight menu's search box, you can control-click a word and use the contextual menu to spell check your search term, or run a Google search with that term, etc.
[robg adds: This may be obvious to others, but I'd never thought to try control-clicking in the Spotlight search box. I'm not sure I'll ever use the feature, but now at least I know it's possible. Obviously, this hint is for 10.4 and 10.5 only, but I don't have a category for "10.4 or newer." As such, I chose to leave it uncoded, given that the vast majority of users here are on at least 10.4. That's how I'll probably treat all such hints going forward, too, unless someone has a better suggestion.]
Even when a Java program doesn't display any windows or other visible elements, if it accesses the AWT subsystem in some way (e.g., to do image processing internally), OS X will still put an icon for the Java program in the dock as if it were a GUI-based app. (When the program quits, the dock icon goes away as usual.)
Because of this behavior, even console-based Java programs sometimes have icons show up in the dock. This is most noticeable in apps like Eclipse that launch console-based Java programs for background processing. Dock icons will sporadically bounce into view and then disappear as the Java programs are launched. It's very distracting, and it's not how Java behaves on other platforms.
Although there doesn't seem to be any global fix for this problem, one solution can be applied on a per-app basis. You will need to modify the command that launches the Java program so that the java.awt.headless system property is set to true. For example: