These ten bugs were filed on Wednesday night. Seeing as I'm just posting about them on Sunday, I figure it evens out to Friday.

The 14 bugs from last time were pretty much the first bugs I noticed in Leopard, but they haven't really been problems at all in my regular use; these ten are the most annoying issues I've encountered in my regular use — these ones either wasted a lot of my time or constantly get in my way.

CXXVII (redux): Copying two items in sequence can result in the failure of both due to lack of disk space. This is a pretty stupid bug: suppose you have a disk with 2 GiB free. You start a copy of one item that is 1.5 GiB in size. The Finder determines that there's enough disk space and allows the copy to proceed. Immediately you start a copy of another item that is also 1.5 GiB in size. Since the first copy hasn't yet copied 0.5 GiB of data, the Finder again determines that there's still enough free space to copy the second item and lets it proceed. Eventually, both copies fail because they are both competing for disk space.

Basically, the Finder doesn't take into account any currently running copy operations when assessing the amount of disk space left over. Filed: 5610478.

(CXXVII from last time was marked as "behaves correctly" according to Apple and I agree: Dock menus for stacks don't actually have two redundant items. It's just that in Column view, "Reveal in Finder" and "Open [stack name]" appear to do the same thing, whereas in Icon view, the former opens to the stacks enclosing folder, while the latter actually reveals the stack's contents.)

CXXXVI: Calling up the character palette or keyboard viewer result in two lines to the Console that indicate these panels use deprecated calls. They're not really annoying, except that I don't particularly like to wade through extra lines in the Console when assessing problems with other apps. (Yes I know about the Console's search box.) Filed: 5610481.

CXXXVII: Disk Utility doesn't perform file checksums anymore. This one bug caused me days of frustration when I was trying to repartition my MacBook so that I could have both Tiger and Leopard installed at the same time. Here's what I did:

I imaged the original 60 GB (yes that's GB not GiB) drive and saved it onto my external hard drive, and then reformatted and created two partitions, one about 20 GB in size and the other 40. The original image was made from a 60 GB drive, but it had 35 GB of data on it, and I wanted to restore it to the new 40 GB partition. Disk Utility in 10.5 was having none of it: there apparently just wasn't enough space. I looked in hdiutil's manpages and it specifically said that read-only UDIF and NDIF disk images remove free space in addition to traditional compression. So why weren't my disk images restoring to the smaller partition?

Finally I looked in asr's manpages, and hidden in the description of preparing an image for restore was the "--filechecksum" option. This was exactly what I needed.

Before disk images are restored to a disk, they need to be prepped for restoration. This is called "imagescanning". You can do two types of prepping. One does block checksumming, and the other does file checksumming. The former calculates checksums for individual disk blocks, and the latter for individual files. These checksums check the integrity of the data as they are written to the destination.

If the destination drive is as big or larger than the source image, then the block-by-block restoration method is used. However, if it's smaller, then Disk Utility does a file-by-file restoration method instead. First, this requires that the total space of the destination drive is larger than the amount of data on the source image. (The source image can be of any size, as long as the amount of data is smaller than the total space of the destination.) Second, though, this method requires file checksums to have been calculated during the imagescan.

Apparently, Disk Utility in 10.5 no longer performs the filechecksumming by default. You have to manually do it via the command line, using asr imagescan --source /path/to/src.dmg --filechecksum. You should then be able to return to the Disk Utility GUI and perform a restore as usual.

What's particularly annoying is that I was able to restore from larger source images to smaller destination drives with 10.4. There doesn't seem to be any documentation on the change, and there's no option to even change Disk Utility's default behavior back to 10.4's way of doing things. So now, if you want to do this, you have to drop to the Terminal temporarily. Not a big deal for me, except for the two or so days I wasted converting the image of my hard drive around to various formats. Filed: 5610486.

CXXXVIII: Disk Utility now requires you to manually do imagescanning before you can do a restore. What's the point? If the user requests that an image is restored to a drive, why not automatically do the imagescan and then restore the image? 10.5's Disk Utility now simply generates an error to the user, telling them they need to imagescan the image before restoring it. Pointless. Filed: 5610492.

CXXXIX: Synching calendars via .mac from Macs running Leopard to other Macs running Leopard seems to have problems. Whenever I try this, I get an error saying that the sync failed due to inconsistencies in the data, and that I should check that they are correct and then do a reset sync. Problem is, the reset sync generates the same error. WTF? There are tons of people having the same problems in the Apple Discussions forums, and the only way to fix it seems to involve unregistering all your computers from .mac. Fuck that, I'm filing a bug and turning off Leopard-to-Leopard calendar synching for the moment. Filed: 5610513.

CXL: Safari fails to display RSS feeds when CPU is under load or free disk space on system drive is small. That pretty much sums it up. It's annoying, too, because if Time Machine is doing its hourly backup or I'm converting video files, Safari's RSS display repeatedly fails with the same error message: "Mach errore 268451843 - (ipc/rcv) timed out" or "NSMachErrorDomain:268451843". Under the same conditions, Safari fetches and displays normal webpages perfectly fine. Filed: 5610533.

CXLI: Mail displays a blank preview pane sometimes when selecting e-mail messages. It's sporadic, but for a second you just think that Mail is taking a bit to render the message and then you realize it's not. To rectify the problem, you have to select a different e-mail and then select the original one again. Filed: 5610537.

CXLII: This one's also annoying, because it screws up my automatic e-mails in response to purchases of my software. If an AppleScript uses Mail's scripting dictionary to create new mail messages, and this AppleScript is called in response to a rule that the user has set up in Mail, the AppleScript will fail. Try this: create a new AppleScript with the following code:

using terms from application "Mail"
        on perform mail action with messages theMessages for rule theRule
                tell application "Mail"
                        set mymail to (make new outgoing message at the beginning of outgoing messages with properties {subject:"Test Subject", content:"Test Body"})
                end tell
        end perform mail action with messages
end using terms from

Save it as a script. Now create a new rule in Mail, have it match any e-mails with a subject of "Mail Script Test Bug", and have it run the above AppleScript as an action. Then send yourself such an e-mail.

Lines similar to the following should show up in the Console:

2007-11-21 2007-11-21; 22:36:23 Mail[178] *** Assertion failure in -[MailDocumentEditor load], /SourceCache/Mail/Mail-914/Compose.subproj/DocumentEditor.m:322 
2007-11-21 2007-11-21; 22:36:23 Mail[178] An exception was thrown during execution of an NSScriptCommand... 
2007-11-21 2007-11-21; 22:36:23 Mail[178] load must be called on the main thread

This didn't happen in 10.4. Filed: 5610546. Someone forgot that NSAppleScript's aren't thread-safe — an annoying limitation of NSAppleScript, I might add. Sad that it isn't changed in 10.5.

CXLIII: Clicking on the Desktop sometimes refuses to bring the Finder to the front. Workaround: click the Finder's Dock icon. I have no idea what triggers this problem. Filed: 5610554.

CXLIV: I believe this has occurred in 10.4 as well, but when you type on the bottom line of a textarea in Safari 3, the focus ring that indicates that the textarea is active acquires gaps as you type. Filed: 5610563. Here's a pic:


That's all for this set. Maybe next Friday, maybe not. 10.5.1 ABF Review if I feel like it.