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.


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
    } else {                     // copy fail
        message("Move failed");

This is where the problem with the Mac OS X 10.5.0 Finder lies.


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:


MacBook Pro (2.0 GHz Core Duo, 2 GB of RAM)
Mac OS X Leopard (10.5.0)


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”).

leopardbug1.png leopardbug2.png leopardbug3.png leopardbug4.png

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).

leopardbug12.png leopardbug13.png

Where’s the rest of our data?

Apple, please FTFF already. This is unacceptable.

Words From Others

Hay adminstrator . Why dont you add facebook badge on your blog ? Thanks Good luck


September 28th, 2010

Darius Alme

September 18th, 2010

Hay Admin , i read with Your idea. LOL Please come to my blog


August 30th, 2010

????????? ????????? ? ? ??????, ? ? ???????.??????????? ?? ??????? ? ?????? ???????, ? ?????? ???????????? ????????, ?????? ?? ????? ???????? ???????? ?? ????????????????? ???????.???? ??? ??????? ??????????? ????????? ?? ????????????.?? ???, ?????? ?????? ????, ????? ?? ??? ????????? ????? ?????.????????????, ? ??? ????? ? ??????? ???? ??????????? ?? ?????? ??????, ? ???.? ?? ????? ? ????? ???? ??????, ? ???????? ?? ??? ???? ????.? ?????? ????? ????????? ???? ????? ????? ?????? ?? ??????, ????? ????????????? ??????? ????, ???? ?????? ??????? ???????? ??????????????.


June 2nd, 2010

OK, I believe that the transfer between 2 macs over ethernet is giving me the same problem, just found some scrambled images in random folders. I have a large photo DB to manage. I don’t believe that there will be any software to fix the damaged images, what I want is to be able to FIND the corrupted images easily… so as I can replace them from the backup HDD’s. Photoshop when opening them says that they could be damaged or truncated, but opens them anyway. I have tried using backup software and virus software to ‘catch’ the bad files but none have shown up. I have seen similar corrupted jpgs on DVD’s in storage, after 5 or 6 years, it was driving me crazy as the system would just lock up trying to copy the DVD, eventually I found software to copy the good files only, and ‘jump’ the bad ones.


May 27th, 2010

I have the newest update of snowleopard and this problem is still not fixed. The reason why it doesn’t work is the following: When mac OSX are moving/coping files it starts with making an “placekeeper/repository” for the file before it actually moves/copies the file into this “placekeeper”. The mounted folder which you are trying to copy has settings activated in a way that gives user no right to edit/delete files after they are placed there. As you can understand the problem is then that when mac OSX is first making this “placekeeper” for the file, before starting the acutal datamoving, the “placekepper” file is allready locked, and the real data cannot be transferred into the “placekeeper”. All you have to do is to change the right of the files in the serverdirectory in a way that makes everybody able to edit/change and delete files. Then it will work i think.

Sry for my bad english, I am Norwegian.


March 3rd, 2009

Hello webmaster I would like to share with you a link to your site write me here


February 26th, 2009

I’m not sure whether Paulo understands the bug, or is just an example of how bad reading comprehension can lead to hazardous interpretations …

Paulo Nascimento

November 23rd, 2008

Actually I don’t know if this is a real problem or a proof of uncontroled stupidity leading to hazardous consequences. Still meditating about it…


October 27th, 2008

Good words.


July 8th, 2008

Hi Tom, thx for sharing this. Hope Apple will move quick on this now. As I thought its important that people know.

vishal dwivedi

May 29th, 2008

very nice knowledgebase article for data loss due to leopard bug. in case of data loss you can use mac recovery software such as stellar phoenix data recovery mac software which easily recover your mac data.

More details on:

a tiny some1

May 10th, 2008

I came across this bug while using the 10.5.2 version. a serious prog fault. bad strt wid the new os :(


April 15th, 2008

This particular bug was fixed in 10.5.1. If some user or other is still experiencing some form of data loss when doing moves, then it must be unrelated to this. :-

The Finder has and always will be weird. ;-)


April 14th, 2008

Hi Tom,

Thanks for all of your reporting on this bug - this still appears to be about the best source on the net for information on this issue. Just checking if you could provide more info on the resolution to this issue - I know you say this issue has been fixed, but I have a user on 10.5.2 who has reported a similar issue when copying files to a network drive. Can you point me to anything on Apple’s site that describes this condition (and its fix), or did this all pretty much just go away with 10.5.1? Just thinking that another “Final Resolution Update” or something at the top of this entry might be helpful for poor saps like me who are still trying to troubleshoot Finder weirdness in 10.5.2. :-(


March 7th, 2008

What is a “human check” going to give you? Are you going to compare the copy byte-for-byte?

Look, if you can’t trust your operating system to properly do a copy, then you have some serious issues — either with the OS, or with the hardware.

A “move” is exactly that — a copy, a check, and then a delete.

I’ve never encountered an error like this before, but it’s old news anyway, because this has been fixed since 10.5.1.

Andy Merrett

March 7th, 2008

OK, it’s a bug, and a big one at that, but I NEVER initiate a MOVE across volumes anyway, period.

It’s one more manual step, but if you’re moving that much data between volumes, COPY it, do a HUMAN CHECK to ensure it’s copied, THEN delete the source.

OK, maybe you shouldn’t HAVE to, but I’m sure I’ve encountered this sort of thing in the past on other systems.

Good Credit

January 4th, 2008

I’ve been thinking lately that being frugal is not a bad idea. My credit history is not that great mostly because of lat payments on credit cards. But I still feel like the only way to rebuild it is to get another credit card and quickly pay it back. Which one do you feel will work among those at

discover credit card 0% or life



December 21st, 2007

i have OS 10.5.1 and i grab a folder full of stuff and copy it to my network disk. But im amazed wen i open the copyed folder i n the network disk it’s empty?!?!?! I i’ve tryed in other mac’s with the Tiger system and it copies fine…. why is this new Leopard so Buggy?!?! I’, an apple fan but stuff like this gives me a PC feeling:!:!:!


December 18th, 2007

Apple SUCKS!


November 24th, 2007

Thanks for sharing this detailed demonstration. I’m not sure if my article about garbled JPEG-images on copies from smb shares under Leopard 10.5.1 concerns the same insane bug, but for those who are interested:

Jean Pierre

November 16th, 2007

I just wanted to let you know that this bug really seems to have been fixed in 10.5.1.

I can confirm the correct behaviour (for now; on USB devices) after I too suffered from data loss due to that bug a few days ago.


November 13th, 2007

Wow, just read this and it could not have come at a more appropriate time. Just went to a client this morning who has an Art Dept of about 5 macs. they connect to a SMB shared windows directory. Last week something happened and they lost everything. Seemed to be a problem with one machine making the connection and I think when the connection was lost, that is when everything went “poof” It blames it on a the Macs. They are not running Leopard. They are on 10.4.10 down to 10.39. They were able to get back some data but not all. I think they are sending the drive out for a more complete recovery effort.

They work directly off the server, what is everybodies take on that? Should they copy the file to the desktop, work on it there and they put back on the server? If I am reading the previous posts correctly, that’s not a godd idea either.

By the way, this has nothing to do with the “bug”. The client has no back-up in place. That’s a whole another issue.

Jason Belec

November 13th, 2007

Came across this page when looking for other things. This is a pain in the hiney bug and has been around quite some time. It’s an issue with OS X to Windows/Linux whatever. It’s really frustrating with WEBDAV, but are you sure the data is lost? I’ve seen this quite a bit and it usually results in the FInder not seeing the files, but they are still present in the directory. It is weird that all files in the directory take a powder though. Copy seems to always function properly though. Have you tried forcing the Finder to rebuild it’s index?


November 11th, 2007

Stop trying to defend Apple with your contorted logic. Expecting a feature to work safely, and to work just like it works in every other sane OS is “self-righteous indignation”?

This isn’t a “naked move” by design, it’s a “naked move” by bug. There’s absolutely no reason why the source should be removed if it hasn’t been copied correctly. If that doesn’t convince you, perhaps the changes in 10.5.1 will: They’ve fixed the bug.

A move isn’t a dangerous op in any other OS — that should tell you something. I’ve never been worried about doing a move of stuff on to a destination, because I’ve always trusted the OS to delete the source only if the copy returns success. This is the way it has always worked in Windows, in Linux, in FreeBSD, and in every other OS I’ve tinkered with in the past.

Not even OS X does this underneath. The Finder’s implementation is the only one that differs — and it has nothing to do with buffering. It’s simply a failure to observe and act on the copy’s return value.

joseph daniel zukiger

November 10th, 2007

Well, I am of two minds about your self-righteous “Spec Doesn’t Meet User X’s Obviously Correct Expectation!!!” indignation at this.

My Unix background makes me uncomfortable with any mv that fails to follow the

if ( copy( destination, original ) == SUCCESS) remove( original );


But the power user knows about holding the command key to induce the naked move should be a power user who knows better than to use a naked move without having a backup already in place. Attempting to move data from one volume to another when it is possible to lose the connection to either volume is something of a game of Russian roulette by definition.

The fact that you have to be so careful to explain how to force the move, and to draw attention to the feedback, should tell you something.

If you were complaining that the naked move is not hidden under a more obscure and more difficult to accidentally invoke key combination, that would be a valid complete (but would require re-defining a part of the user interface that has been in place since years before Macs could, in standard configuration, easily lose a mount in mid-move).

They moved the finder’s new folder function from the orthogonal and traditional command-n to shift-command-n to match browser function, so it would seem reasonable to ask them to move the naked copy to something harder to hit, like shift-command-drag. And it would be reasonable to request that they replace the naked move with a buffered move on the easier to hit command-drag.

It would also be reasonable to add a note to the progress window indicating the degree of danger in the move. And it would be reasonable to add a note to the failure notice to indicate the extent of potential damage. Since it puts up a notice anyway, it would be nice to have a cancel option when a buffered delete aborts early.

But then, it might be more reasonable to want them to focus more on their work with file systems that can be rolled back.

Anyway, a naked move is a naked move, and really shouldn’t be used unless the backups are already in place.


November 8th, 2007

Tried to reproduce the same thing moving a 650Mb ISO from Mac Pro with Tiger to B&W G3 with Panther, and the bug didn’t show up. The Finder hangs for a while when the Network volume disappeared but the Test folder and these ISO inside of it where still there.


November 8th, 2007

“My comment about not being in the trash still stands as correct. When moving a file the file is NEVER placed into Trash so you’re NEVER going to get anything from Trash anyway.”


“The reference to the file is NOT deleted as such it’s merely flagged as being deleted.”

No. When a file is “deleted” in the Finder, it is MOVED to the Trash. The Trash is a hidden directory in your Home directory. Don’t believe me? Check the full label of the “Undo” option under Edit after you “delete” something in the Finder. It begins with “Undo Move of …”

“In theory you should be able to do a Command Z which will return it”

Incorrect. The Finder, when it does a move operation between volumes, actually does truly delete the sources when it believes that it is done copying. The problem, once again, is that it never verifies whether those files/directories were copied over correctly. It just goes ahead and issues a file-system-level “delete” operation. This is NOT the same as a “Move to ~/.Trash” operation.

“All I’m saying is have you tried Command Z? If not then the next time it happens see if it works. If you have then that’s fine but you never said if you actually tried it. If you never tried it because the file never showed up in Trash then you’re not really listening to people who are trying to offer valid suggestions for helping.”

Those people don’t really understand the issue at hand.

“I know for a fact that Command Z can undo a move which by your reckoning shouldn’t work because the file has been “deleted†from its original location.”

Correct — when a file has been moved from one location to another on the same volume, or when a file has been successfully moved from one volume to another. When a file does NOT get successfully copied to another volume as part of the move operation, there’s nothing really to “Undo” … is there? (Because both files are gone, from the source AND the destination). The Finder doesn’t have built-in data recovery capabilities so as to “undo” a real delete.

Loweded Wookie

November 8th, 2007

Don’t take this the wrong way but I don’t think you do know what you’re talking about in this case.

My comment about not being in the trash still stands as correct. When moving a file the file is NEVER placed into Trash so you’re NEVER going to get anything from Trash anyway.

The reference to the file is NOT deleted as such it’s merely flagged as being deleted.

In theory you should be able to do a Command Z which will return it, but I agree that theory is great until it comes to practise.

I’ve not been able to replicate this problem so I’m not really commenting on what is happening in your case but in a more general view, I’m also not trying to lessen the impact of what’s happening to you either.

All I’m saying is have you tried Command Z? If not then the next time it happens see if it works. If you have then that’s fine but you never said if you actually tried it. If you never tried it because the file never showed up in Trash then you’re not really listening to people who are trying to offer valid suggestions for helping.

I know for a fact that Command Z can undo a move which by your reckoning shouldn’t work because the file has been “deleted” from its original location. What I don’t know for a fact is if it will work in your situation, I was merely trying to offer something you could try. What harm can it do to try, it’s not like you’ve got anything to lose.


November 7th, 2007

Yes, some massive speculation on check out the facts at see this:,00.shtml


November 7th, 2007


Because it’s not in the Trash means one thing for certain: You can’t get it out of the Trash. You can’t undo the action either because the files have been deleted.

I’ve never said anything about the possibility for recovery. Trust me when I say that I know what I’m talking about. All deleted files can still be recovered if you haven’t done any writing to the volume. If there has been write activity, all bets are off.

So I was correct in saying that the files don’t exist and can’t be recovered from the Trash (nor can they be recovered via Undo). A recovery utility may still be able to help.

Loweded Wookie

November 7th, 2007

Because it’s not in the trash doesn’t mean a thing.

I just moved a file (mind you local) and was able to undo the move.

Just because the file system can’t see it doesn’t necessarily mean it’s not there. If it was the case there would be absolutely NO way you could ever restore files except from backup.


November 7th, 2007

Yeah, this happened to me with Tiger I believe it was. Trying to copy something to my PSP. I ~thought~ I did everything I needed to do, then later I check out my 2G MemStick and it’s completely empty. Game saves? Gone. 5 or 6 Albums of MP3s? Gone? Demos? C’ya. Me? Pissed!


November 7th, 2007

Nothing. The files don’t exist anymore. They’ve actually been deleted (not just moved to the Trash, for instance).

Loweded Wookie

November 7th, 2007

What happened if you did a Command Z to undo?


November 7th, 2007

@zimmie: are you nuts?


November 7th, 2007

Finally someone gets the word around about this. It’s not new in Leopard, had it in Tiger as well!

Decided to move home folder to another partition, cancelled after the first three files - source was no longer there, destination contained only these.

Reproduced quite a few times to make sure it wasn’t something else. Since then I’m using the command line to move or copy!

Oh, and did report to Apple back then, but any error reports (and I think I usually write good ones) sent to Apples feedback address seem to get ignored.


November 7th, 2007

kenny: The bug has apparently been around for years — reporting it again to Apple wouldn’t do much good. What’s the matter, though? Did I hurt your ego? Are you losing sleep because of the Vista fanboys rubbing this one in your face? And yes, my camera does have a “zoom-out” button. It was zoomed out.

mr big: Ah yes, the typical Apple apologist response — instead of basically taking it for what it is (the potential for huge data loss performing a simple system operation), you tell the user that they should be doing things differently. I’ve said it before, and I’ll say it again: The suggestion to copy/verify/delete manually is exactly what a sane OS should be doing on its own in the first place when you move something. Mac OS X fails at this. Apple fails at this. It needs to be fixed. No apologies.

simon: Well said. Frankly, I had no idea this post would make such huge news in the tech world. I’m surprised my shared hosting has withstood a Digging and Slashdotting as well as it has.


November 7th, 2007

People. It’s a bug, get over it. Is it a bug that can’t be worked around? No. Does it single-handidly mean that Leopard is unusable? No.

Just face the facts. On this one, Apple screwed up. Let’s move on.

Mr Big

November 7th, 2007

What’s this all about? I have always found in any application or operating system several ways of achieving the same goal. If what you are doing causes a problem then desist doing it. I have been using Apple Macs now for ten years or more as a tech and on my own computers. I have never come across this so called problem. What I have always done is when I want to copy on the same volume a file or folder, is to duplicate it and then move it into the folder I want it on that drive, simple and as for moving a file or folder to another volume, I just drag and drop it even simpler. Sometimes I move between 40 and 100 gigabytes of pictures at a time. Copying a file or folder without confirming everything copied correctly is just bad practice!!


November 7th, 2007

Does your video camera not have a zoom-out button?


November 7th, 2007

Have you never heard of rather than showing your dirty laundry in public?


November 6th, 2007

If you Mac fanboys truly do care about your OS, quit candy coating your problems or comparing them with supposedly crappier OS’ and see to it that Apple fixes its problems.


November 6th, 2007

i long ago gave up any hope that apple would actual do any serious QA with osx :-( …

when an organization doesnt have UML or SDL as a core part of engineering culture, then it is no surprise that so much shoddiness goes on for so long.

this bug belongs to the long-standing (and ever-growing) list of apple’s laziness/stupidity/incompetence.

err -51 … maybe it is a close cousin of the phantom ACL err -36 that has also plagued us for years and years!

osx makes me look back upon System 7.5 and Netscape 4.x as (relative) paragon’s of engineering prowess :-(

osx’s interaction model is so broken (threads; scheduler; etc) that CONSOLE registers more clock-time for hanging apps than it does for productive work.

Please, someone remind me again why i loathe windoze so much?!


November 6th, 2007

I was able to confirm this for Leopard, but I ran the same test in Tiger and didn’t loose any data at all. I’m guessing that this is a leopard only bug.


November 6th, 2007

ooopss…, what have I done…!? ;-)


November 6th, 2007

Aha! So this is what you think about while spending time with me! :’( Sob, sob.


November 6th, 2007

copycat: Indeed. I was thinking about this while out for a walk with the girl. :-P If you find yourself facing data loss the moment you are faced with that OK button, you can still rescue your files.


November 6th, 2007

But you can still enter a “cp -R” command in Terminal to make a copy of the file somewhere else as long as the Error code -51 is shown in Finder. Just don’t hit OK. Tested it myself right now, worked!


November 6th, 2007

mike: That’s precisely what an OS move operation should do — copy, confirm, delete. OS X doesn’t. That’s the bug.


November 6th, 2007

Oh, and … jasarien: Leopard’s screenshot facility now captures the entire window and its drop shadow around it, but as PNG transparency — meaning that it’ll look great on any background you put it on.

Just hit Apple+Shift+4, then press Space to go into window-screenshot mode.


November 6th, 2007

ummm… why are all you people doing a move anyway? it’s bad protocol to ever do a command that deletes a file after a copy without confirming everything copied correctly. now, the archive install problem is a different story, as this is something apple should fix (change it to copy then delete, not move), but for the general user, doing a move command between volumes is a stupid habit and you are asking for trouble. period.


November 6th, 2007

blang: Cool, thanks. I don’t mind that at all. :-)

mike: Why don’t you give it a try then, big boy? If you understood file systems and IO operations at all, you wouldn’t have bothered suggesting that.

erik: For the one such movie I might record a year, how about you buy me a tripod? :-)

alexandre: Take a look above for my link. ;-) Someone already asked.


November 6th, 2007

Excusing this flaw because it wasnt documented is a cop out. OSX stands out amoung operating systems by delivering a majority its functionality via easter eggs, and using the command key for a move operation is just another one of those easter eggs. If a feature isnt supported it shouldnt be there.

Alexandre Gauthier

November 6th, 2007

Great article, and not that is is in any way related, but could you possibly share the wallpaper you used in your virtual machine? It’s nice and easy on the eyes.


November 6th, 2007

Yeah, I’ve encountered this problem frequently when copying media files from the the internal HDD (on both PPC and Intel systems running 10.4.X) to a FAT32 formatted iPod HDD… Moving of files is something I do frequently and have never had a problem in various different MS Windows environments, I was pleased to discover this fairly hidden feature by accident and have used it many times, but having has the finder crash on me whilst moving files (numerous times) and subsequently losing the data, I no longer move files… Instead I copy them… Then delete the source once successfully copied… I was really hoping that Leopard would’ve fixed this problem and am frankly appalled to hear that it hasn’t… It’s a fairly basic operation with a MAJOR flaw… I’d be able to live with the finder crashing, but losing the data loss is a serious affair!

Mark Petereit

November 6th, 2007

Time Machine makes all of this moot, right?

Jeff Sepeta

November 6th, 2007

i just wish they would implement the look-ahead copy features of copydoubler/speeddoubler into the OSX finder (which broke after the upgrade to MacOS9)

Sean Swayze

November 6th, 2007

safe computing says: never (NEVER) perform a move operation on files that are: a. important b. not backed up This is in safe computing 101. While I agree that move operations should be able to be performed safely, there are a host of difficulties that can (and often do arise) i.e. power loss, network outages, faulty cables, etc. Safe computing will not expose you to this bug. Sure it takes more time to perform a copy, diff, delete, but you’ll not lose important 1s and 0s.


November 6th, 2007

Buy. A. Tripod. Seriously.


November 6th, 2007

Weird. I tried it myself using the movie you provided and i didn’t lose any data at all.


November 6th, 2007

I have been using Macs for 18 years and System 6 allowed the ability to move files from one volume to another. And for most of those 18 years I have been doing exactly that, without loss of data.

Just don’t move data when a storm is brewing and you’re likely to suffer a power outage. As a support person I can also say that most if not all problems are “operator error”.


November 6th, 2007

I have a solution!! EDIT…UNDO MOVE OF FILE. Sweet Jesus that was a tough one right there.


November 6th, 2007

I was just wondering how you managed to take those screenshots so well. How did you get the drop shadow and the transparency without capturing the background too?

Fernando Marcos

November 6th, 2007

I had already seen this type of problem in tiger, moving files from a USB pen to my hard drive. So, it’s not an exclusive bug of leopard, apple simply doesn’t bother fixing it.


November 6th, 2007

I also noticed this with Leopard. It was nice to notice that I lost a 2GB I just downloaded. Nice to download the file again :P


November 6th, 2007

Hi Tom, thx for sharing this. Hope Apple will move quick on this now. As I thought its important that people know, I posted your video on youtube, of course giving you full credit and posting a link to your site. If you however do not want this, just drop me a line and I’ll take it offline right away. Please don’t sue me. ;) greetz from the Netherlands, Guido


November 6th, 2007

Did you file this bug? Maybe it would be a good idea if you post your rdar://xxxxxx here, so other people duplicating this behaviour could put your rdar://xxxxx into their notes, when they file this bug themselves. the higher the dup count is, the quicker this bug will be fixed.


November 6th, 2007

STFU you moron


November 6th, 2007

I was bitten by this on day 1 of upgrading to Leopard. It’s definitely not behaviour exhibited by Tiger, and it ONLY seems to affect Finder—it’s not a core OS-level bug. “mv†and friends work just fine, because of the way they move files.


November 6th, 2007

There is a similar Finder-bug (both on 10.4 and 10.5) which silently forgets files with “odd” (e.g. containing particular Japanese characters) filenames copied from an NFS-mount. If you move a folder containing such files, it’ll also delete the uncopied files which it overlooked! >_< rdar://5217201


November 6th, 2007

@danoz: It’s going out of your way because you have to do extra work to do it. Most people would never think to hold down a modifier key while dragging files. I didn’t even know that there was a way to move files between volumes until I heard about this. Similarly, most people have never heard of file permissions, let alone ACLs.

I’m with hamranhansenhansen. The bug is the fact that the Finder lets you move things between volumes at all, not that it fails under some circumstances. It should be fixed by eliminating the move operation. Then again, I support UNIX-based systems all day, and I’m sick of people moving critical files to random locations on other partitions.

I also love how the comment system ate the line breaks in my directions.


November 5th, 2007

fwiw: I just tested this on Tiger 10.4.10 (MBP CD2) by connecting to an AFP volume (on a different Tiger box) and turning off airport in the middle. Got the Finder error dialog, but it didn’t delete the test folder.

David Newall

November 5th, 2007

I think what is occurring is an effect of write-back caching, which operating systems use to improve performance.

When you ask to write a file, the operating system (OS) stores the change in RAM, but delays actually writing to disk until later. The OS reports a successful write and lets you continue with your work, on the assumption that the disk-updates really will take place as expected. This enormously improves performance. It lets you continue your work which, in the case of a move across volumes, would be to remove the original file (this also will be reported as successful before actually being committed to disk.)

Without realising it, you caused the loss of data by interrupting access to the disk (or server.) You can probably specify a mount property or flag, probably called “synchronous”, which will physically write to disk (or server) before permitting you to continue your work; it really will slow you down.


November 5th, 2007

The bug to me is that there is a move command at all between volumes. You can’t move stuff between volumes, only copy it.

What is the advantage of the AVI movie over ISO MPEG-4 H.264/AAC?


November 5th, 2007

Have you submitted this to Apple via They’re usually fairly responsive to formally submitted bugs.

Steve Cummings

November 5th, 2007


For the present I find myself with all Tiger home network, in the past I could have tried to repeat this on a BSD, Linix, Windows setup.

Has anyone tried the disappearing volume move on another BSD platform at least? Windows.

It would be nice to move the data first, and then reclaim space once completed (with checksum?).

But, I’m going to ask those with multiple platform systems what their experiences are.

Solaris anyone?

W. Ian Blanton

November 5th, 2007

This was apparently reported on MacInTouch on Nov. 2nd. I’ve confirmed it by cutting SMB services while transferring, and it definitely happens in Leopard. I’ve also confirmed it does not affect 10.4(.9) Client.

Additionally, if you MOVE several folders, and the connection is cut, only one folder is affected. This is of course, still bad, but not as bad as it could be. Apple definitely needs to fix this.


November 5th, 2007

zimme: how is holding down the apple key to perform a move instead of a copy going out of my way? i’ve done this thousands of times in the past and never had this problem before…


November 5th, 2007

I ran into this myself just the other day, never had this problem on any previous version of os x. I was moving about 2Gb of files from my desktop to an smb share, it failed with an i/o error of some sort and poof they all disappeared, very frustrating seeing as i was putting them on the share so that they got properly backed up.


November 5th, 2007

I wouldn’t call this a massive data loss bug. You have to go out of your way to move a file to a remote share rather than copy it. My pet ACL bug is comparable.

mkdir test cd test touch Foo chmod +a “[yourUserNameHere] deny delete” Foo rm Foo

The system should return “rm: Foo: Permission denied”.

cd .. rm -rf test

The system should return “rm: test/Foo: Permission denied”, then “rm: test: Directory not empty”.

Now, drag the directory ‘test’ to the Trash and empty it. The directory and the file in it will be deleted.

In both cases, you have to be doing something weird to encounter the bug.


November 5th, 2007

Wow, you got /.’d Tom. Nice one.


November 5th, 2007

What wallpaper are you using on the virtual pc?


November 5th, 2007

I know this bug and it definitely is not new. It seems to me it was Tiger, though I cannot rule out that it was Panther. Anywa, I lost a huge number of pictures from a flash drive a while back because I was doing a move and bumped the ccable and the drive lost connection to the computer. Really stinks to put it mildly. I never use move based on that experience. I use only copy and then go back and delete the files at a later time.


November 5th, 2007

Good reason to stay away from anything Windows.

Ric Ford

November 5th, 2007

See a very similar data-loss bug from Mac OS X 10.1 here:


November 5th, 2007

lesterbangs: Drop me an e-mail and I’d be glad to help you out.

dtnick: It appears to affect any destination type — so pulling the plug on a USB drive would cause it to happen as well.


November 5th, 2007

Could this be why I lost 100 Itunes songs and my Entourage archive file of all my emails?


November 5th, 2007

You’re unacceptable. -Steve J.


November 5th, 2007

^^ignore my first question. I see it was answered at the very beginning of the article.


November 5th, 2007

Does this issue only affect SMB file sharing? And if you list the ~/Desktop/ directory in the Terminal, is the test folder still missing??


November 5th, 2007

this is completely off-topic but how did you get the neato colorized prompt in yer bash shell? i know you do it via a ‘export prompt’ command but i’m too lazy to figure out the magic incantation.


November 5th, 2007

Aha. I wasn’t aware that this bug existed pre-Leopard.

It’s still something that should have been fixed, given the fact that the Leopard Finder has received the biggest overhaul in Mac OS X history.


November 5th, 2007

Just curious, as I’m too lazy to set up my own test environment…does the same problem occur when you’re in a terminal session and use ‘mv’ to move the files?

Just curious.

Bill McCloskey

November 5th, 2007

So, if I do this from the command prompt i.e. # mv test /Volumes/smbfs, is there an error?


November 5th, 2007

Did you check the trash?

Scott Perry

November 5th, 2007

Welcome to 2003.

This is not a Leopard regression and thus is not a good reason not to upgrade.

Steven Fisher

November 5th, 2007

This was in Tiger, too. Does Apple actually document that you can hold down the command key to move the file instead of copying? (Not that I think it shouldn’t be fixed, but I’m a little less concerned if a feature that doesn’t officially exist doesn’t work well.)

Zero Gravitas

November 5th, 2007

I hate to say but this bug has been around since Panther.

Jean-Francois Roy

November 5th, 2007

Please file a Radar at It’s the only way this is going to be fixed promptly.

Bob Wallace

November 5th, 2007

I encountered this problem last December while setting up a new iMac running Tiger. Never imagined it would be so common or repeatable. Thanks for documenting a repeatable scenario.

David Hopper

November 5th, 2007

Well this would absolutely explain why my /Library/Receipts directory was empty after my Archive and Install. The Installer crashed at the end of the process, deleting my Receipts from both source and destination.

The problem is that this is baked into the Installer DVD. They’ll have to recall / cut new ones once this bug is eliminated.

Andrei Kolev

November 5th, 2007

Thanks for the tip! I was considering myself a power user and I had access to prerelease versions but I was not aware that there is such a feature in Leopard. Well, I am not going to use it yet but I hope it will be fixed soon.

Stephen Chiang

November 5th, 2007

Yeah, I found this bug the hard way on Friday when I was moving a couple of large MP4 files to an external eSATA drive and the copy failed during the move (a different unrelated bug that occurs when a large file is transferred to a Seagate 750GB Freeagent Pro drive using the eSATA interface when connected to a Tempo SATA Express34 card in Leopard). I reported both these incidents via ADC bug report website on Friday evening. I hope these bugs get fixed soon. Coming from a Windows environment, I actually use move quite a bit!