Sparse disk image data loss Since we posted a reader report yesterday that claimed restarting or shutting down while a sparse disk image is mounted leads to data corruption on the disk image, we've received a number of confirmations that the procedure described produces data loss. Reader Marc Marshall provides details on his own testing:
"I tested this on a dual 1GHz G4 running 10.3.1. 10MB and 100MB sparseimages, even those with just two or three small files on them, had the files corrupted after a restart with the image mounted. A 500MB sparseimage was also affected, but only if there was more than a few megabytes on it; roughly the first 50MB were fine, but any files over that were corrupted after restarting. I also tried adding more data to the partially corrupt 500MB sparseimage, and although the data was readable after copying, it too was corrupted after restart.
"In these cases, the order that the data was added to the disk image seems to be the deciding factor (later=corrupted), not the files' location in the directory. The .DS_Store files also seemed to be corrupted, since affected directories didn't seem to remember their organization. When I opened the affected files in a hex editor they appeared to contain mostly zeros (one file had a few bytes of nonzero data toward the end).
"In all these cases, the images could be unmounted and remounted manually without affecting the data on them."
We've also received a couple of reports from readers who followed the procedure but did not experience data loss, so this may not be a universal issue.
A number of readers have asked if this situation is somehow related to the problem with FireWire drives becoming corrupted in Panther when restarting or shutting down without first unmounting the drives. Other readers have asked if this issue is related to the FileVault bug in OS X 10.3 (FileVault uses a sparse disk image). Although we don't know the cause of the current issue being reported, it doesn't appear to be technically similar to either the FireWire or FileVault problems. However, it is troubling that there now appears to be at least two different issues in Panther where volumes can be damaged if they aren't unmounted before shutting down or restarting.
Internet Sharing issue with Jaguar Reader Alastair Cutting reports an issue where Internet Sharing doesn't work if the computer sharing the connection (i.e., the computer connected to the Internet) is running 10.3.1 and the computer(s) connecting to that computer (i.e. sharing its connection) are running Jaguar. According to several threads (1, 2, 3) on Apple's Discussions forums, the same computers worked under Jaguar, but upgrading the "Sharing" computer to Panther breaks Internet Sharing.
We haven't verified this problem ourselves; if you've been successful or unsuccessful sharing an Internet connection from a Panther Mac to one or more Jaguar Macs, drop us a line.
Bluetooth menu (and other menu) issues Yesterday we covered a report by a reader for whom the Bluetooth status menu disappears whenever attempting to send something to his Mac via Bluetooth. We've since received a few confirmations of this issue, as well as a number of reports of other status menu issues. Reader Jim Hassinger, for example, notes that for him, Apple's "Network Connection" [we assume he means modem or AirPort connection status] and volume menus, and the third-party Salling Clicker status menu are unreliable: "They just seem to come and go."
Icon issues in Recent Items submenu Earlier this week we covered a reported issue where documents in the Recent Items submenu of the Apple Menu have incorrect icons. We have verified this issue on at least one of our systems, and we've received confirmations of the problem from a number of other MacFixIt readers. Although this appears to be solely a cosmetic issue -- documents open in the correct application when selected from the menu -- it's still an odd phenomenon.
Finder authentication issues We previously reported on the fact that after logging in to an admin-level account in Panther, that account is authenticated for five minutes, allowing the user nearly unfettered Finder access (e.g., the ability to move or delete system-level files, accidentally or on purpose). We posted an "unrecommended" workaround submitted by a reader that involved editing the /etc/authorization file to reduce the authorization time from 5 minutes to 0.
In addition to the inconveniences and warnings posted along with that procedure, reader Mike Barron reports another side effect: "for me it had the negative effect of making the settings in the Directory Access application unchangeable"
Panther problems? Drop us an email at Lateemail@example.com.