Massive Data Loss Bug in Leopard
November 5th, 2007 :: 206 comments
Update: The bug occurs regardless of the type of destination being moved to (whether it’s local USB, local Firewire, SMB, etc.). Also, I have been informed that this bug goes back all the way to Panther.
Update 2: Here’s a video of the same thing happening to a USB drive: leopardmovebug.avi
Update 3: Robert Rodgers adds: “I accidently chmod’d a directory while a massive (40+GB) file move was being copied into it to be -w by me, files went ‘poof’.”
Leopard’s Finder has a glaring bug in its directory-moving code, leading to horrendous data loss if a destination volume disappears while a move operation is in action. I first came across it when Samba crashed while I was moving a directory from my desktop over to a Samba mount on my FreeBSD server. If you still have any issues in regards to data loss, lifelock data security plan to protect you against damages that might come from identity theft due to data loss.
I’ve now run tests on a Windows XP SP2 SMB mount, as well as a local HFS+ formatted USB drive, and the bug surfaces every time the destination disappears while the Finder is moving something to the destination.
Details
Before I go into more detail, let’s clear up what it means to “copy” or “move” a file:
Copying from/to the same volume: A new file reference is created on the file system, and then data is read from the source and written to the destination.
Moving from/to the same volume: The file reference is modified to reflect the new path. No data is ever read/written.
Copying from/to different volumes: A new file reference is created on the file system of the other volume, and then data is read from the source on the original volume, and written to the destination.
Moving from/to different volumes: A new file reference is created on the file system of the other volume, and then data is read from the source on the original volume, and written to the destination. If the previous operation is successful, the original file on the original volume is deleted.
As you can see, moving a file from one location to another on the same volume is a piece of cake. Moving a file between two volumes really incorporates two file system operations: a copy, and then a delete … but only if the copy was successful (at least on a sane system!).
In terms of pseudo code, moving from/to different volumes might look something like this:
move(source, destination) {
returnVal = copy(source, destination);
if(returnVal == TRUE) { // copy success
delete(source);
} else { // copy fail
message("Move failed");
}
}
This is where the problem with the Mac OS X 10.5.0 Finder lies.
Demonstration
The following is a simple demonstration that anyone with a SMB server (be it Windows itself, Samba on FreeBSD/Linux, etc.) can duplicate. The specifications for the demonstration were as follows:
Client
MacBook Pro (2.0 GHz Core Duo, 2 GB of RAM)
Mac OS X Leopard (10.5.0)
Server
Same MacBook Pro running VMware
Windows XP SP2
For my purposes, I simply booted up Windows XP in VMware and connected to it as if it were a whole separate computer (OS X doesn’t know the difference).
Let’s go through the regular rigmarole of finding a Windows PC’s IP and connecting to it through SMB (“Windows File Sharing”).
Great. We now have C:\ mounted on our Mac running Leopard. Let’s prepare for the simulated SMB mount failure by opening Computer Management\System Tools\Shared Folders\Sessions in Windows.
Our Mac’s connection to the share should be obvious.
Let’s now open a Terminal on our Mac, and create a directory with some garbage data in it. Generate enough data so that a move operation will take at least 10 seconds. In my case, my test file is 384 MB.
(The command I used to generate the test directory with a garbage file is as follows: mkdir test && dd if=/dev/random of=test/testfile bs=4096 count=98304)
You’ll now see a "test" directory on your Desktop.
Here’s the key step. Move the "test" directory from your Desktop to the C$ mount by holding Command (Apple) and dragging. Dragging without holding Command will initiate a copy operation (that’s what the plus means), so be sure to hold Command until you release the drag.
You’ll know Finder expects to perform a move when there is no plus beside the directory you’re dragging.
Okay, our move operation is doing its thing. (Notice how the title of the window still says “Copy”? Remember what I said about moving files across volumes?)
Quickly go back to the Windows session, right-click on the active share session, and close it.
Finder will error out with one of its typically useful error messages and codes. This much is to be expected. The "test" directory can still be seen on our Desktop.
Aaaand … poof!
The directory on our Desktop is now gone. The directory shown in the C$ mount will only contain files that were copied entirely before the connection was disrupted, but nothing more (in the demonstration case, there’s only one file in "test", so nothing was copied successfully).
Where’s the rest of our data?
Apple, please FTFF already. This is unacceptable.
add to 
add to 
add to 
national academy of health and business
October 2nd, 2010