|Home » Industry Watch
The QuickBooks Disaster
It works as designed. By Apple. Terribly.
Mac OS X users upgrading to QuickBooks 2007 are finding their entire desktop folders hosed. Gigs upon gigs of important files are permanently gone as the installer replaces the user desktop and all files and directories with a single file - the QuickBooks installer.
On no other system in existence has this ever been allowed to happen. Only on systems sold by Apple. And to make matters worse Apple's esteemed engineers have for years now insisted this is 'behaves correctly works as designed expected behaviour'.
'tangrams' tells a story.
I opened Quickbooks and it said there's an update. It started trying to download it automatically but then it said it couldn't because I didn't have enough disk space and that I needed 100 bytes for it to download. It's rubbish because I had at least 2 gigs free. Then Quickbooks started and I tried finding the update from the menu and it found it but said I couldn't download it because I wasn't on the network when I was. Then I noticed that all the icons on my desktop had disappeared. I checked and all my files in my Desktop (there were quite a few) had disappeared.
I opened a Finder window and Desktop was gone from the left sidebar. I checked my user directory and Desktop did not exist as a directory anymore. I logged out. Logging back in recreated a Desktop directory for me but it was empty. I restarted. Desktop was still empty but I had 2 additional gigs of disk space.
During this entire time there was nothing in Trash.
It's obvious what's happened and although Intuit made a mistake they're not the real culprits. The real culprits are Apple and they've understood this issue for at least five years.
What's Really Going On
Apple have long insisted calamities such as these are 'expected behaviour' and there are ample links at the end of this page for further reading. But in a nutshell it's this.
Apple file management APIs don't allow 'complementary' or 'merge' file operations. All Apple file management APIs fail if the destination already exists. And this means that client applications such as the Intuit installer must first remove the destination before writing to it.
Unix doesn't allow overwriting directories with files (or vice versa). Rixstep's Xfile doesn't allow overwriting any file system object with another object not of the same type; but this is additional 'band-aid' code implemented as Microsoft, Bare Bones, TextMate, and others have also done to prevent disasters of this kind (and magnitude).
Apple's official word - as found in the links below - is that this 'works as designed'.
If file operations were 'complementary' the destinations wouldn't have to be removed first; if they weren't removed then the operations would fail at the next step because overwriting a directory with a file is categorically not allowed.
Apple's 'cheap' and convoluted way of handling file management and 'passing the buck' forces companies such as Intuit to resort to 'unsafe' methods which no other self respecting operating system would ever allow.
And Apple want to know why this company refuse to submit any more bug reports to them?
If shame doesn't get them perhaps a few juicy lawsuits can.
Apple's File System APIs
Developers Workshop: Y.G.B.K.
Hotspots: Leopard: OS Xhumation
Developers Workshop: performFileOperation:
Hosing OS X with Apple's Idea of 'Expected Behaviour'
Learning Curve: Rebel Scum: More Attacks on 'Expected Behaviour'
Apple: NSWorkspace Reference
Apple: NSFileManager Reference
Slashdot: Data Loss Bug In OS X 10.5 Leopard
Tom Karpik: Massive Data Loss Bug in Leopard
MacInTouch: Mac OS X 10.5 Leopard: Finder Data-Loss Bug
Learning Curve: 4893378 FAQ
Industry Watch: Sanity Checks at Apple
Learning Curve: A Sanity Check for Apple
Learning Curve: 4893378: 'Expected Behaviour'
Apple Support Discussions: Desktop GONE
QuickBooks Community: QUICKBOOKS UPDATE DELETES DESKTOP