I’ll post some cute pictures and other stuff later. :-P

You four power-tripping, murdering pigs better be held accountable for the death of a poor guy who was just scared out of his mind. It doesn’t take an above-average IQ to figure out that a foreigner left alone in an area of the airport, not knowing the language, or even knowing where he is, is going to get agitated, and then quite frightened. And way to go, airport staff, for helping him out.

Many of us will see these videos over and over again in the next few days. And since a video is not tainted with bias or personal interpretation, it will be made clear to everyone that the intention to taser said victim was there from the start — unprovoked.

Fuck you four, and everyone who stands behind you in your defense.

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.

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.