More on Finder crashing when previewing PDFs Yesterday we reported a problem with the preview function in the Finder when attempting to render miniature versions of large PDF files. We've now received several notes of confirmation for this issue, including one particularly detailed message from Joe Schram:
"At our Ad Agency, we have been seeing this same issue on Panther since at least 10.3.2. It is exactly the same situation that Neil describes; as soon as the PDF file is selected, immediate Finder crash and restart. Another wrinkle is that sometimes the crash happens if a folder full of PDFs is selected in column view, or if it is triangle-opened from List view.
"We've attempted many fixes for this problem as it is not happening on all systems, only with users who are specifically dealing with a large number of InDesign-direct PDFs each day. We've tried repairing permissions, running Disk Warrior, reapplying the Mac OS X Client Combo updaters, clearing caches with Cocktail, and even using several of the ".DS Store cleaners" found on versiontracker.com. Nothing has worked or has even changed the faulty behavior.
"The empirical evidence initially suggests that the Finder's built-in support for previewing PDF files is the culprit, and that it could happen due to complex or corrupted PDF documents whose built-in preview thumbnail is unparseable by the Finder. Even that is a shaky theory though, because I have found a workaround via the Terminal. If a PDF file that causes the crash is copied out of its original directory via the GUI, the copied file will also cause the crash. However, if the PDF file is copied via the "cp" command in the Terminal, it appears that the copy will not cause the crash. We have been using "cp" at the command-line to move these troublesome PDFs onto the Desktop where they can be selected, opened, and used as normal.
"We were hoping that 10.3.3's listed fix 'Addresses an issue in which Finder unexpectedly quits if the View menu option 'Show icon preview' is enabled while dragging a significant number of icons to another location.' would solve the problem, but I confirmed today that it has not. Just for the heck of it, I tried again with the Finder's "Show icon preview" option on and also with it off; still crashes."
Booting from/mounting FireWire drives Continuing our coverage of problems booting from and mounting FireWire drives after updating to Mac OS X 10.3.3, readers have found some interesting solutions:
Jens Verwiebe writes "I had the same problem with firewire devices recognized but not mounting. This happened in 10.3.2 and 10.3.3. Exchanging the IOFireWireFamily.kext to the old version 1.7.0 ( from 10.3.1 ) solved the problem. Now with IOFireWireFamily.kext 1.7.0 (Sept 2003) its all OK."
You can find the IOFireWireFamily.kext file on your original Mac OS X 10.3 installation CD (with the help of a tool like Pacifier), or by searching for the file (both visible and invisible items) on a system running Mac OS X 10.3.1 or Mac OS X 10.3.2.
Chris Ptacek reports that files installed by Avid Free DV were the culprit for his mounting problems: "So I remember a few days back that someone has suggested that the AVID files in the library were causing them problems with mounting USB and FireWire drives. Then I remembered that I had installed Avid Free DV when it first came out. I also remember there being an un install script that was loaded once you ran the installer, but I had backed that up to my external. I downloaded the newest Free DV and installed, rebooted and presto, my drives came back. Now I also had the un installer script which I now ran since I never used Free DV rebooted and everything is still working fine."
Zip drives We continue to receive reports of problems with Iomega Zip drives - particularly 250 MB models - after updating to Mac OS X 10.3.3.
Eric Shapiro found an odd process of booting into Mac OS 9 then back into Mac OS X allowed access to his externally powered Zip 250 driver: "Since my upgrade to Mac OS X 10.3.3, my USB powered Zip 250 drive refuses to mount at boot-up. If I re-boot into os 9.2, the drive mounts normally on the desktop. Then, a reboot in 10.3.3 and presto, there's the zip drive.
"After shutting down, if I start up again in 10.3.3, the drive is gone again. The access light blinks, and the drive spins up, but the disk doesn't mount on the 10.3.3 desktop. I have to go through the re-boot into 9.2 each time, in order to see the drive.
Another reader confirms the exact same behavior:
"After upgrading to 10.3.3 the zip icon vanished from the desktop. I couldn't eject since it didn't show anywhere. The profiler did indicate it's existence but couldn't find a way to remove the disk. After re-applying the upgrade and running disk utility, permissions and fsck the condition persisted. Since I had a copy of OS 9 in another partition I booted into it and the Zip icon appeared on the desktop. I quickly removed the disk and rebooted into OS 10.3.3. After the desktop was ready I chanced inserting a zip disk and lo-and-behold it appears on the screen showing no ill effects in it's contents. I have since discovered, however, that if I don't eject the zip before re-starting it will again fail to appear on the desktop requiring another trip to the OS 9 system."
Thomas Greer found that he had to eject media during a certain point in the Zip spin-up process for proper mounting "My zip drive also is failing to mount. It will mount briefly at startup or on wake up. The lights flash it spins the disk and then everything stops and the icon disappears. There is no access to the drive at this point. I've found that you must eject the disk during the period when the light is flashing during boot up. Or, unplugging the drive and ejecting the disk when you first plug it back in. When you reinsert the disc, the drive mounts normally. this happened after the install of 10.3.3. The easiest way to get the drive to work is to eject the disc when you are done with it, making sure its out when you boot up or awake from sleep."
John Sawyer reports that (oddly) placing his drive horizontally resolved problems with mounting "After upgrading to 10.3.3, my USB zip drive was unable read any disk inserted requiring a manual ejection. I could hear the drive making a repetitious sound as it continually tried to access the disk. I wondered if the drive was being affected because it was in a stand sitting vertically. After removing the stand so that the drive is sitting horizontally, I've had no trouble reading or writing to disks."
By far the most widely successful solution, however, is removing all IomegaWare files from your Mac OS X 10.3.3.
Bill Zinn writs "I had to delete the Iomegaware files using the uninstall option in the Iomegaware download. I can now read and write to USB Zip disks just like before upgrading to 10.3.3 However, none of the disks that I had previously written to, using 10.3.3, would work properly. I could mount them and read them, but couldn't write to them. After saving all of the data on the disks, I tried erasing/reformatting them. I was able to make a few usable, but thus far I have three that I can not repair."
Meanwhile, we've received word from Iomega's customer support department that updated drives for Panther are on the way. Mason, a support representative writes "I would like to inform you that Iomega has not stopped supporting Iomega Zip Drives on Mac 10.3 System. Iomega is working for developing IomegaWare software that will be compatible on Mac 10.3 System. I can not assure you about the exact time frame, when the software will be released, however, I will suggest you keep checking Iomega web site for the next release IomegaWare software."
Possible solution for some sleep problems Trevor Harley found that unchecking "Wake for ethernet network administrator access" in the Energy Saver pane of System Preferences resolved the deep sleep issue.
"I have had a lot of problems with sleep ever since installing the last security update - problems not resolved by 10.3.3. Essentially it is now virtually impossible to get my Macs to go to sleep - either automatically or from the menu (the machine sleeps, and awakes within a couple of seconds).
"However, I seem to have discovered a fix - for me at least. Unchecking 'Wake for ethernet network administrator access' under options in the energy saver control panel appears to have solved the problem."
More on the Finder folder deletion quirk Yesterday we reported on a quirk in the Mac OS X 10.3.3 Finder where users receive the message:
'The name "untitled folder" is already taken. Please choose a different name.'
when attempting to delete a newly created folder in list view. MacFixIt reader Gerrit DeWitt offers a few more observations on the issue:
1. The folder deletion quirk does not occur if the new folder is created on the desktop. Pressing command-delete will result in the name changing briefly (to something like "untitled folder 2") before the folder disappears into the trash.
2. The folder deletion quirk is not specific to the name "untitled folder." Create a new folder (other than on the desktop) and name it "funny"; press command-delete to send it to the trash. Now repeat the process and the Finder displays the dialog that the folder's name is already taken. (The second and subsequent folders of the same names are still moved to the trash, but their names are returned to "untitled folder N," where N is an integer greater than one.)