Unfortunately, a bug in Snow Leopard may mean you're not seeing all the Services you should see in the contextual menu that appears when you right-click on a document or a text selection. You can, however, make those Services appear in the contextual menu:
Open the Keyboard System Preferences panel, and select the Keyboard Shortcuts tab.
Select Services in left-hand column.
Deselect and reselect the Services you wish to appear in the contextual menu.
After toggling, the selected Services now appear at the bottom of the contextual menu. Credit isn't mine -- I found the details of this bug in Rob Griffiths' write-up on Snow Leopard's Services.
[robg adds: I had totally forgotten I'd written about this bug, and it seems it's still present in 10.6.2 (as tested on a new install here). It's also a bit more complex than I originally stated -- there are some Services that, even though they'll show in the Services menu, won't show in the contextual menu even after the above trick. It's not clear what the logic is for what will or will not show up, so you'll need to experiment a bit.
To demonstrate the problem, select some text in TextEdit, and then Control-click on the selection. Any relevant Services should appear at the very bottom of the menu, including two Mail-related entries (New Note With Selection, New Email With Selection) and one for Stickies (Make New Sticky Note). If you don't see them, perform the above toggle trick, and they'll miraculously appear.]
On my Mac, Time Machine backups sometimes slow to a crawl, and stay like that for hours on end. After some digging, I discovered that Finder is often the culprit, and quitting Finder seems not to have any adverse impact on the backup -- but it does speed it up by an order of magnitude. Here's what happened in my case...
I had been making an initial Time Machine backup over a network. Initial write speeds were over 5mbps, but an hour later, it was down to 100kbps -- and CPU usage went up to almost 90%. I left it this way for four hours and there was no improvement -- at this rate, the backup would take a week.
A look at Activity Monitor showed almost all the CPU usage due to Finder, and a look at the 'Open Files and Ports' by Finder showed it accessing the Applications folder in the backup, crawling through all the application packages over and over again.
Fed up, I quit Finder and suddenly backup speed went back over 5mbps -- and the backup finished absolutely fine.
I don't know what Finder was doing, but it doesn't seem like anything crucial (I didn't notice anything in the logs). This was only seen on Snow Leopard, and over a network (although this happened to me with a FireWire backup device as well.).
[robg adds: I haven't seen this on my Macs, but if you're having Time Machine backup issues, it might be worth a look.]
Note that the output above is set up for GeekTool, where you don't want a newline. If you want to run this in Terminal, you can change the printf bit (in either version) to read ...2f%%\n..., which will add a line break at the end.]
It bugs me that Time Machine won't backup my encrypted home folder, provided by File Vault, while I'm logged in. I rarely log out of my account, and that makes Time Machine pretty useless in my opinion. I wanted some way to create a backup while logged in.
I'm more concerned about my laptop being stolen than my backup drive, since it's sitting in my closet, attached to my AirPort Base Station. So the fact that the backup won't be encrypted with this hint is no big deal for me. As a side effect, it makes single file restoring much easier. (One caveat being that Time Machine complains that it can't find the original location of the file, since it treats the home folder as a disk and not a path on the startup disk. You need to manually select that.)
To sum it up: I need my home folder to be encrypted. I don't need my Time Machine disk to be encrypted (but I'm sure someone can come up with a way to accomplish that, too.) Read on for the how-to...
To make it easier to retrieve accidentally-deleted items from the trash, you can use an Automator workflow and the third-party Automator action Touch Files to create a "date deleted" time stamp on files placed in the trash. Here's how:
Download the Automator action and unzip it.
Open Automator and import this action (File » Import Actions and navigate into the Touch Files folder to find the Action).
Create a new Folder Action workflow in Automator.
Click the Choose Folder pop-up at the top of the workflow, and select Other. When the file choice dialog appears, type Shift-Command-G, then type ~/.Trash/ and click Choose.
Drag the Touch Files action (you can find it under Files & Folders) into your workflow. I recommend checking the Apply to contents of folders option, otherwise if you delete a folder, its files' modification date will remain unchanged.
Save the Folder Action with a relevant name (Set Modification Date or whatever).
Now when you add a file to the Trash, its modification date will change. Sort the Trash window by date modified, and your most recently deleted files will be at the top.
[robg adds: This worked very well in my testing -- just make sure you give the workflow a second or two to run before checking the modification date. It worked on both files and folders with the option checked as described above. This is a nice solution to finding the most-recent of multiple similar/identical files you've deleted. One caveat: this will only work for files you delete from your boot drive; if you have other drives connected, items deleted from those drives actually go into a different folder (/Volumes/volume_name/.Trashes/501). I'm not sure if there's an elegant solution for handling any arbitrary connected drive or not...readers?]
Many applications that relied on Java 1.4.2 and Java 1.5 stopped working in Snow Leopard, because Apple removed these Java versions from the system. Upgrading to the lastest versions of many applications usually will solve the problem. However, your favorite application may not have a Snow Leopard compatible upgrade. For these applications, re-installing Java 1.4.2 and/or Java 1.5 is necessary. Sometimes, even this is not enough. As an example, Apple also removed the Cocoa-Java bridge from Snow Leopard, which some Java applications such as PDFLab depended on. Reinstalling the Cocoa-Java bridge along with the proper version of Java is necessary to re-enable these applications on Snow Leopard. For example, getting PDFLab working again in Snow Leopard requires reinstalling Java 1.4.2 and the Cocoa-Java bridge. Read on for a how-to...
One of the major annoyances about Mac OS X 10.6 is that screen savers now have to be compiled as 64-bit to work. This means that any old screen savers that you may have collected will now appear in gray in the Desktop & Screen Saver System Preferences panel. If you try to select these grayed-out entries, the system will tell you that the screen saver is incompatible, and ask you if you want to move it to the Trash.
Many screen savers are no longer in development, but worked just fine in 10.5. If you have a screen saver that you liked in Leopard but that no longer works in Snow Leopard, first see if the developer has released a Snow Leopard version, or is working on one. If the developer seems to have abandoned the project, as so many do, see if he has made these screen saver open source.
For example, this port of XScreenSaver, which contains over 200 screen savers from Linux, has both binary and source available for download. The binaries are compiled for 32-bit and work just fine in Leopard, but they will not work in Snow Leopard.
The solution is quite simple: you can recompile them yourself in 64-bit mode.
In Leopard, for Quick Look to display the contents of a text file, its extension had to be 'registered' with its UTI in the Info.plist file of the application associated with the file extension (see this hint). For most file endings associated with applications, this already works out of the box (in short, for all files with a Finder icon). This still seems to apply to Snow Leopard, but there is another option which might be new to Snow Leopard.
To make the file Quick Look-able, one simply has to set an extended attribute identifying the file as a text file. The necessary attribute is com.apple.FinderInfo with the value TEXT!Rch. Setting extended attributes can be done via with the xattr command in the Terminal. Note that xattr is technically a script and not a shell command, and thus does not have a man page, but help is available with xattr -h.
In my testing, I was only able to set the value in hex format. For a file named foo.goat this looks like this:
I recently upgraded from Mac OS X 10.4 to 10.6, and noticed that the power saving profiles have disappeared from the menu bar's Battery Status menus. Luckily, this functionality is still accessible via the command line.
Open Terminal and type the following command in order to set the profile to be used when using the battery:
pmset -b modenum
Replace modenum with one of the following values:
1 - Better Energy Savings
2 - Normal
3 - Better Performance
-1 - Custom
In order to set the profile used when connected to AC power, change -b to -c. I am able to use the above commands with neither administrator nor root privileges. Your settings should be reflected in the Energy Saver preference pane.
As many people may know, Apple made it all but impossible to run any screen savers on top of the login window (i.e. after some time, a screen saver appears over the login window) in Leopard by tightening up security requirements on processes that can run over the login window via launchd. This made workarounds that worked prior to 10.5 impossible to use. (The only screensaver that I know of that can run behind the login window in 10.5 is this one.)
I'm happy to report that, as of Snow Leopard, running screen savers behind the login window is finally officially supported. This was brought to my attention by magnusviri in this Apple Discussions thread .