The first time I open /users/shared using an alias, the folder comes up with a sidebar, even though I've repeatedly set it to turn off the sidebar. Strangely, the animation appears to be opening the folder twice. If I then close the folder and re-open it, it shows up without the sidebar, just as I've configured it in previous sessions. From then on, every time I open the alias, it comes up without the sidebar.
But if I log out and back in, I get the strange first-time behavior again, with a double-animation and a sidebar. If I use the Finder's Go -> Go to Folder menu for the first access, I can get to the target folder without the double-animation and without the sidebar. But the first time I use the alias, it shows the double-animation and the sidebar, so it really appears to be related to the alias. (I've tried re-creating the alias and even tinkering with it's extended attributes.)
I've done four fresh installs of Leopard (exploring security settings), and I've seen this behavior every time, so I'm pretty sure it's an as-delivered bug. I'm running on a PowerPC iMac; this may or may not happen on the Intel Macs.
To avoid this GUI display problem, I've found that I can make Unix symbolic links instead of aliases. For example, to create what appears to be an alias to /Users/Shared on the Desktop, you can type the following command in Terminal:
$ ln -s /Users/Shared ~/Desktop/Shared
This seems to reliably create a link that respects your view settings, at the expense of a little less use of the GUI. It's hard to believe Apple's own alias technology is messed up, and good old Unix links work better. It would seem they've forgotten the adage "'tis a gift to be simple."
If you're using Time Machine to back up Macs to a Time Capsule or networked hard drive, each backup is contained in a single sparse disk image bundle (.sparsebundle) disk file. When your backup contains weeks' or months' of data, if that single file is lost or damaged, you'll obviously lose all of your backups. It is therefore quite important to back up the sparse bundle and test the backup! Here's one way to do that that, though there are many other methods available:
Copy the sparse bundle back to your Mac (and then remember to exclude it from Time Machine's backups, using the Options button in the Time Machine System Preferences panel).
Use Disk Utility's Repair Disk feature on the mounted .sparesebundle to insure that it's in good shape. This should be quite fast when run on the local copy of the sparse image bundle.
If Disk Utility doesn't find any issues, you've now got a good backup of your critical Time Machine data. If you do this even once a month, that will greatly limit your losses should the sparse image bundle go bad or accidentally get deleted. While this may seem like overkill, the first time you have a sparse image bundle go bad, you won't think so.
[robg adds: I've had my MacBook Pro's Time Machine backup go bad a couple of times now, so I've taken to copying the sparse image file onto the Mac Pro as a redundant backup. I keep it in a folder that has been added to Time Machine's 'do not backup' list, so that it's not taking a ton of space in my Mac Pro's own Time Machine backups. If you have only one Mac, I suggest attaching a FireWire hard drive and using that to store the copy of your sparse image bundle, as drive space on a laptop is a precious commodity.]
Time Machine automatically excludes hot folders like /var/tmp and /var/vm and Library/caches from its backups. But it does not exclude, by default, the Downloads folder.
If you are like me, things in your Downloads folder are mainly transient items that have not yet earned the status of permanent guests on your hard drive. So add this to your list of excluded items by using the Options button in the Time Machine System Preferences panel.
I invite readers to add comments suggesting other overlooked folders with lots of churn that should not be backed up by default.
I use a big external monitor at work, and carry my MacBook around. I've found that Spaces is not much needed when I have two monitors rather than one. However, bringing up Spaces System Preferences panel just to toggle Spaces on and off is a pain.
So I wrote a small AppleScript that toggels Spaces on and off:
After much experimentation with the various known techniques and applications for turning off Spotlight indexing on a volume, I have concluded that it is not possible to convince OS X (Leopard) to not index the volume being used for Time Machine.
This is true even if Time Machine is set to Off, its volume is added to Spotlight's Privacy list, and the volume has a .metadata_never_index file at its root. The volume I was using is a partition on an external FireWire 800 drive dedicated to Time Machine.
My guess is that Apple enforces indexing on the Time Machine volume to facilitate searching backups, as suggested in this knowledge base document. But there are many ways to search, I don't use Spotlight all that much, the volume is 400GB, and I really just don't want Spotlight chewing on it -- especially when there's no way to control the frequency at which Time Machine does its backups.
[robg adds: Note that you can actually control the frequency with which Time Machine backups run, as discussed in this hint.]
You may occasionally notice Time Machine is backing up an unexpectedly large amount of data, or maybe you're just curious as to what actually changed between backups. Perhaps you'd like to tailor your exclusion list to keep the backup size down. Unfortunately, the Time Machine interface provide no means to find out what it is actually being backed up. Luckily, we can use the fact that Time Machine creates hard links of unchanged files to explore what it did back up, after the fact.
timedog is a Perl script (4KB download) which does just that. Use it like so:
$ cd /Volumes/TM/Backups.backupdb/myhost
$ timedog -d 5 -l
By default, timedog will examine the most recent backup, compare it to the one prior, and report all changed files. The -d flag controls the directory depth of reporting, -l disables reporting for symbolic links (for which Time Machine seems to create a new copy of the link each backup). You can also specify a backup of your choice as an argument, though it must also have one prior backup with which to compare.
This script should be safe, but standard warnings apply regarding mucking with your TM database.
[robg adds: I haven't tested this one; the script should already be marked as executable, so it should run after download without any changes.]
Here is a way to re-order the login items in your user's Accounts System Preferences panel. (Whether this is actually useful, as those items now load asynchronously, is another question entirely.)
Click and hold on a login item, and drag the item a little bit down and/or right. Notice that a dark line will appear at the bottom of the list of items in the login panel. Release the mouse button, and that item will be moved to the bottom of the list. Not as convenient as "drop to the location of your choice," of course, but with a modicum of planning, you can re-order your list this way.
[robg adds: As noted, login items now load many-at-a-time, so I'm not sure reordering them makes any difference, other than possibly making them easier to find in the list.]
Since the release of 10.5, I've seen that the execution of AppleScripts triggers heavy activity of syslogd, basically causing it to take over the CPU. I've found that by killing the syslogd process (which will automatically restart) and removing the asl.db file from the /var/log directory, I can at least temporarily solve the problem.
Here's a two-line AppleScript to do just that:
do shell script "sudo launchctl stop com.apple.syslogd" with administrator privileges do shell script "sudo rm /var/log/asl.db" with administrator privileges
Run that, and CPU usage by syslogd should drop to normal levels again, at least for a while.
[robg adds:This older hint covers another issue with a runaway syslogd process, this one apparently caused by Time Machine.]
I was digging through my old email archives the other day, when I stumbled on one that explained how to use Quick Look on documents in Open and Save dialogs. The trick? A free AppleScript Quick Look Droplet, provided by none other than Apple themselves.
There are actually two little apps on that page -- Quick Look Droplet, and Quick Look Viewer. The first is just what you might guess it is -- drag and drop any file or files onto its icon, and you'll get a Quick Look preview of those files. The second is a miniature media player, of sorts. You can store files inside the application bundle, and those files will be shown in Quick Look when the program runs. So you could, in theory, place the desired documents in the application bundle, then distribute that bundle to customers as a demo of your work, without worrying about them having the proper tools to actually open those files.
But I really like the Quick Look Droplet. Store it in your Dock, and you can then drag a file from an Open or Save dialog onto the Droplet, and you'll see a Quick Look preview of that document. The only minor issue is that these two apps are using qlmanage (see this hint) to show the previews, which means things don't work quite like they do in the Finder. You can't, for instance, close the Quick Look window with the Space Bar. However, I love having Quick Look in the Open and Save dialogs, so much so that I've given this droplet a spot in my Dock.
To make the changes take effect, logout and login, or restart SystemUIServer.
[robg adds: This works, and I activated it with killall SystemUIServer in Terminal. To add the shadow effect back in, delete the newly-added pref: defaults delete com.apple.screencapture disable-shadow, then restart SystemUIServer again.]