OS X 10.6 Trash – Can’t Delete Files in Trash Because They Don’t Exist

It is my understanding now that all Time Machine backups after the initial one are a diff of the previous backup, not a disk image. So deleting these folders would render subsequent backups useless (I think).

Fortunately that is not the case. Time Machine backups are complete backups, but they share the disk space with previous backups for the files that have not changed (using hard links). As long as any of the hard links is available, you can access the file.

So if you have a big file in Monday's backup, and the file has not changed on Tuesday, the same file will exist in Tuesday's backup as well, but it will not take up any extra disk space. You can safely delete Monday's backup, and the "copy" for Tuesday will continue to work.

The "Preparing to empty the Trash ... Items to delete: [number]" dialogue got up to 1.5 million files(!) before I stopped it. And I don't have permission, even as root, to rm -rf them.

Yes, because of these hard links, there is an insane number of files in a Time Machine backup (they are all counted so many times). You cannot use simple file-based tools on a Time Machine backup, you need something that understands (and preserves) the hard links. For example, if you tried to copy all the files on a Time Machine disk you would end up with huge duplication. The only way to copy/backup a Time Machine is cloning the disk structure (using something like Disk Utility).

The comments have already hit upon some common reasons why Finder will become slower such as corruption or a large .DS_Store file or a large number of documents that will cause the system to display previews of each.

If you really want to trace the IO, you can use the fs_usage command to dump all filesystem activity to a terminal window and optionally grep out results from programs you don't care about and also discarding all the short IO to get a picture of what IO are taking more than a hundredth of a second to complete.

sudo fs_usage -w | grep -v grep | grep -v 0.00

In your edit to your question, the slow IO are not looking like anything suspicious. You can't really get away from launchd - if it is blocking your IO in finder - that would be because the network filesystems are not responding (or the networking is having issues with packets being delayed for very long times).

Sadly, you may need to browse from the phone client if it really is that much faster than Finder and keep watching the IO. Perhaps if you disconnect all network shares, you might see the slow IO go down and be able to conclude you really have a networking delay / problem rather than a Finder / CPU / local problem. I was hoping something would look amiss in the fs_usage dump - but your results seem normal to me as posted.