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.
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?]