Normally when copying Keychain items from one to the other, the Keychain Access program will ask you for your password for each and every item. Here's a time saving workaround.
First, have the destination keychain (which may be the login keychain) and the source keychain, which you want to merge the items from, both opened up in /Applications/Utilities/Keychain Access.
Now change the password of the destination keychain to be empty. You can do this by selecting the keychain, going to the Edit menu, and choosing the item to change the password. You will need the current password (probably your login password) to change this.
The Keychain Access program will probably complain that the new empty password is not secure enough; but you can override this by holding the Option key and clicking OK.
Next, select all items you want to copy to your destination keychain and drag them over. Since there is no password set, you can just click allow for each item. Huge time saver.
[crarko adds: I tested this, and it works as described. Since it is the destination keychain that you removed the password from, remember to reset it (back to whatever you had to type in to edit the password) when you are through.]
I have a mobile account set up where my user account synchronises files and settings between my MacBook and my desktop Mac. Since the desktop Mac has a dual monitor setup, I put the Dock in the bottom position, so it's closer to the middle of the two monitors. On the MacBook Pro's widescreen display, though, I prefer the Dock on the left, to give more vertical height for the other windows.
Unfortunately, due to the account synchronisation, whichever preference I set on one Mac automatically gets set to the same value on the other Mac. However, there's a way to solve this with the use of the Mac OS X defaults system.
What is needed is a preference setting which is specific to a certain Mac, which can be synchronised but will not apply to the other one. Technically, we need to set the preference in the preference domain for the current host, rather than for any host, which is the default (For more details, see Apple's docs). This can be done from the command line by giving the -currentHost flag to the defaults command, like so:
I wrote an AppleScript droplet to manage the settings of Spotlight indexing for a volume. It's called Refocus, and may be downloaded from here.
To use it, drop a volume icon on the Refocus application icon and you'll be prompted to
enter your password. After entering the password, if the dropped volume's
Spotlight indexing is turned on, you'll be prompted to either turn it off,
rebuild it, or cancel. If the dropped volume's indexing was turned off when
dropped, you'll be prompted to turn it on or cancel. If you run the script
without dropping anything, the operation will be performed on your startup
disk. You'll then be asked to confirm that the full path of the disk that
will be re-indexed is the disk you dropped. That path will be a Unix style
path such as '/' for your startup disk or '/Volumes/archives/' for a disk
named 'archives.' The script won't do anything if the disk you dropped
appears in the Privacy area of the Spotlight System Preference pane.
If you want to create a version of the Refocus droplet that doesn't require
you to enter your password each time you drop a volume icon, run the included 'Create
Refocus with Authentication' script. If your password changes, you'll have
to create the droplet again, of course.
Usage suggestion: Keep Refocus in your Dock. If indexing begins after a
volume is mounted and you know you don't want it indexed, drop it on Refocus
to quickly and permanently stop indexing for that volume.
[crarko adds: I haven't tested this one. The downloaded disk image has both the droplet (which can be opened in AppleScript Editor to view the source and the source to the modified script that saves the password.]
Quite a few badly written apps like to create folders in specific locations, and expect them to be there and nowhere else. For example, my ~/Documents folder contains items such as 'Microsoft User Data', 'Steam Content', 'TomTom', etc. Some even create folders in your home directory or worse, at the root level of the hard disk!
Sometimes you can set a different location in the preferences of the application, but sometimes there's just no way. If you move the folder, the application will become hopelessly confused and/or create a new copy where it expects it. You can make these folders invisible, but then you can't easily access them anymore.
Apple released Java for Mac OS X 10.6 Update 3 (and a corresponding Java for Mac OS X 10.5 Update 8) through Software Update shortly after the Back to the Mac event. The general release notes are here and the security fixes are listed here.
However, those are not the most interesting items about this release.
After you performed a Time Machine System Restore, and you start to open some documents in Finder you will get prompts of the kind 'You are opening the application XYZ for the first time. Are you sure you want to open this application?' as if your computer was freshly installed, not having any file/type associations.
Why this is happening: the Launch Services Database was somehow not restored. Its settings were cached, and cache folders seem to be ignored in the restoration process (for good reasons).
If you want to easily and efficiently control/edit the file/type/mime/URL-scheme-handler associations, then I recommend the preference pane: RCDefaultApp
[crarko adds: I haven't tested this one. RCDefaultApp has certainly been a useful tool to have around for a number of years now, and is still good in Snow Leopard. (Removed an erroneous assumption of mine.]
One missing element of Time Machine has been the ability to encrypt the backups. There have been suggestions of ways this can be done to an AFP connected network share using a sparse disk image, but not on a directly connected device. The method below shows how to accomplish this on a local volume.
One of the occasional irritations of working with launchd is that it doesn't naturally expand shell wildcard characters (~,*,?,...). This means that full paths have to be spelled out for all files: an annoyance at best, and an obstacle when commands need to select specific groups of files or do work across different home folders. For example, a command to clean certain files from a user folder when any user logs in, which is simple enough to write in the shell -- rm -f ~/Folder/*.xxx -- fails when written into a launchd plist.
Occasionally the bluetooth process can decide it doesn't want to connect to any devices. Turning bluetooth off means you can't re-enable, but with Bluetooth Explorer, you can force it to do so.
When in this broken Bluetooth state, trying to connect to any Bluetooth device will cause an error. I usually try turning off Bluetooth when it has issues, but in this state it will refuse to turn back on (the menu bar option for 'Turn Bluetooth On' is greyed out). I'm sure a restart would fix, but I've found that if you have the Developer Utilities installed, Bluetooth Explorer.app will do the trick.
Simply start up the app, located in /Developer/Applications/Utilities/Bluetooth/, and it will give you a message about turning on the controller -- ignore this, as it doesn't seem to help. Once it's started, go to the 'Utilities' menu and select 'HCI Controller Selector'. In most machines, I think you'll just have one 'Apple Inc, Bluetooth USB Host Controller.' Select the controller, hit 'Activate', and Bluetooth goes back to normal.
[crarko adds: I don't know if this is just 10.5 specific. I've never encountered the issue. However, the Bluetooth Explorer utility can provide a wealth of information about not just your controller, but any Bluetooth device it can detect. Go to Devices» Show Device Discovery and then select a device and click 'Get Device Info...' It's a handy little app.]