Massive Data Loss Bug in Leopard

November 5th, 2007

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.

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

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.

leopardbug5.png

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.

leopardbug6.png

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

leopardbug7.png

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.

leopardbug8.png

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

leopardbug9.png

Quickly go back to the Windows session, right-click on the active share session, and close it.

leopardbug10.png

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.

leopardbug11.png

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

[…] wrote a fairly detailed article about it on my site (here: tomkarpik.com Massive Data Loss Bug in Leopard), but the gist of it is basically … 1. Initiate move operation across volumes 2. Destroy the […]

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!

Gravatar

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.

Gravatar

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.

Gravatar

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.

Please file a Radar at http://bugreport.apple.com. It’s the only way this is going to be fixed promptly.

Gravatar

Zero Gravitas

November 5th, 2007

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

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

Gravatar

Scott Perry

November 5th, 2007

Welcome to 2003.

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

Did you check the trash?

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

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.

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.

[…] With any new OS there’s bound to be a few problems. Now that hype is dying down a bit, and as Leopard user get down to using the new OS, the bugs are beginning to surface. The biggest one reported to date involves data loss when moving files between different file systems. […]

[…] what else is stupid? Apparently there’s a massive data loss bug in the new Finder. For years — literally, we’ve been complaining about how awful the […]

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.

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

[…] is far from flawless. First, we had OS X upgrades giving users the infamous BSOD, and now we have a data loss bug as well. The mockery of the Windows BSODby Apple in 10.5 seems all too ironic if you ask […]

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

You’re unacceptable. -Steve J.

[…] 有人發現在 Leopard ,使用拖拉方法將檔案由本地主機抄到網絡上的 SAMBA 分享處/另一個宗卷(Volume),事後本地資料會被刪除掉。(是刪除,不是在垃圾箱)就算網絡抄錄不成功,例如抄寫期間 SAMBA 失效、網絡故障,網絡機器固然不能獲得本地主機的資料,本地資料一樣會被刪除。試想像你想將你的 iPhoto library 抄到網絡上的 NAS ,抄了兩個檔案後 NAS 失效所帶來的沉重代價。 本網忠告市民,在同類型的網絡備份作業,可先將要備份的檔案打包(如用 Zip 、 tar 之類),再傳送打包檔案。這樣可減低資料缺失的可能性。 […]

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

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.

[…] Vista sure wasn’t. And now, the more you look, the more you see that Leopard is getting its share of bitching and grumbling. […]

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

http://www.macintouch.com/Archives/ReaderReports/MacOSX/early/mosxreader10.1.3pt08.html

Good reason to stay away from anything Windows.

[…] issue has been covered in detail over on Tom Karpik’s blog.  Here’s the lowdown on this bug: Leopard’s Finder has a glaring bug in its […]

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.

What wallpaper are you using on the virtual pc?

z: That would be http://psychopulse.deviantart.com/art/The-Bait-N-C-Edition-48178244

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

[…] Every day now, I hear how badly Apple’s Leopard sucks. Now there is news of a massive data loss bug. […]

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.

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.

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…

[…] Tom Karpik came across the problem when his Samba crashed (file and print services). OS X | Oodles | trackback No Responses to ‘Verified data loss bug in Leopard’s Finder’ […]

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.

Hmm,

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?

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

Gravatar

Hamranhansenhansen

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?

[…] vom 6 November 2007 07:25 Schwerer Bug im Leopard-Finder Laut tomkarpik.com beinhaltet der Leopard-Finder einen schwerwiegenden Fehler, der im schlimmsten Fall zu einem […]

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.

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.

[…] 技术人员发现苹果最新操作系统Mac OS X Leopard 的 Finder 文件夹移动代码中有一个明显的缺陷,这可能会导致大批数据丢失. 作者在文中截图展示了Mac OS X Leopard在把文件夹通过Samba复制到挂载在另一台FreeBSD服务器的目录时侯出现问题,数据竟然意外丢失了. 内含原文链接. 查看:Massive Data Loss Bug in Leopard […]

[…] 06Nov07 tomkarpik.com » Massive Data Loss Bug in Leopard Leopard’s Finder has a glaring bug in its directory-moving code, leading to horrendous data […]

[…] crashed while I was moving a directory from my desktop over to a Samba mount on my FreeBSD server.read more | digg […]

[…] to horrendous data loss if a destination volume disappears while a move operation is in action.read more | digg […]

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

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

[…] Información: Tom Klapik website, […]

[…] and the move fails in middle of operation, the "original" source gets deleted as well…http://tomkarpik.com/articles/massive-data-loss-bug-in-leopard/and they say Windows is a beta when it RTMs… atleast it can handle basic operations :pNot bashing […]

[…] Tom Karpik vía 9 to 5 mac  fresqui |  menéame | permalink | trackback […]

[…] Tom Karpik has an excellent write-up on this. I got bitten by it on day one of using Leopard (indeed, it cropped up in a discussion I had with David Chartier that day about Airport stability). Kudos to Tom for taking the time to write it up properly with screenshots, and for getting himself Dugg. Chances of Apple rushing out a fix seem quite high, now. […]

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.

[…] No sé cómo clasificar este bug que Tom Karpik nos revela en su blog; de acuerdo, Leopard debería manejar la situación mejor, pero las circunstancias para que te ocurra son más bien raras. Cuando mueves una carpeta en Finder de un volumen a otro, si la carpeta marcada cómo destino desaparece mientras el traspaso ocurre, la fuente desaparece por completo y tampoco se encuentra en el destino. Karpik se dio cuenta cuando estaba moviendo carpetas desde una MacBook Pro a un volumen SMB con VmWare. Raro, a ver que dice Apple. […]

STFU you moron

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

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

[…] Adrian Kingsley-Hughes: This Leopard bug beats anything Vista has to offer. Tom Karpick: Massive data loss bug in Leopard. […]

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.

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?

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

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

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

[…] Fuente:  http://tomkarpik.com/ […]

Buy. A. Tripod. Seriously.

[…] 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. (story) […]

[…] Tom Karpik recently discovered yet another Leopard flaw that can prove dangerous to your data. It seems that during network or external volume move operations the files being moved are deleted from the source volume independent of whether or not the copy operation was successful. […]

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.

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)

http://www.pbcentral.com/features/speeddoubler.shtml

Gravatar

Mark Petereit

November 6th, 2007

Time Machine makes all of this moot, right?

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!

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.

[…] experience and ours are far from unique. Others are pointing out bugs that could cause data loss and even comparing Leopard to […]

[…] Tom Karpik per la segnalazione e, oltre al video seguente che dimostra il bug, fornisce maggiori dettagli ed […]

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.

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 deviantart.com link. ;-) Someone already asked.

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.

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.

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

[…] Quote In terms of pseudo code, moving from/to different volumes might look something like this: […]

[…] points to Tom Karpik who has all the gory details. Now as it happens, I keep almost no data on my local hard drive. I have two LaCie drives, one 80GB, […]

[…] http://tomkarpik.com/articles/massive-data-loss-bug-in-leopard/ […]

Trackback: http://www.dailytech.com/article.aspx?newsid=9561

[…] Enlace | Tom Karpik on massive data loss bug in leopard […]

[…] that means you have to survive the latest bug in Leopard. It seems that someone got confused with the idea of moving files. E.g. copy the files to the new […]

[…] widespread data loss, and its easy to replicate. The issue has been covered in detail over on Tom Karpiks blog. Heres the lowdown on this bug: Leopards Finder has a glaring bug in its directory-moving code, […]

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!

[…] Risiko von Datenverlust beim Verschieben von Dateien auf Windows-Freigaben […]

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.

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

[…] from news.com: Tom Karpik, a computer science student at the British Columbia Institute of Technology, says he has identified […]

[…] Interrupted data move flaw Filed under: OSX, Security — 0ddn1x @ 2007-11-06 22:22:28 +0000 http://tomkarpik.com/articles/massive-data-loss-bug-in-leopard/ […]

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

[…] Un error de perdida de datos critica ha sido descubierta Leopard, reportada por Tom Karpik en Error in Leopard Masiva Peridida de Datos. […]

[…] aren’t the only ones concerned about the bugs in Apple’s Leopard operating system. Tom Karpik discovered a data loss bug in the Mac OS X10.5 Finder, and Monday he posted a detailed description […]

[…] Un descriptif complet de la reproduction systématique du problème est accessible dans un article de Tom Tarpik […]

[…] are not official, but you may want to take steps to back up your data just to be on the safe side. [TomKarpik via […]

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.

[…] Al parecer, aún no hay ningún parche ni noticia oficial de Apple confirmado este problema. Todos los detalles, aquí. […]

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?!

[…] Mac-loving web is abuzz with reports of a problem moving files in the Leopard Finder. If you’re saying to yourself, […]

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.

[…] datos que estábamos moviendo. El fallo es crítico, y parece no haber solución por el momento. El blog en el que se describe el error explica cómo apareció: mientras movía archivos a un servidor FreeBSD a través del protocolo […]

[…] her gün yeni bir şoke edici gelişme. Örneğin şu anda gündemde Leopar’la ilgili ciddi bir veri kaybı sorunu var. Sorunun kaynağı Leopar’daki Finder. Herhangi bir dosyayı bir sürücüden […]

[…] Mac-loving web is abuzz with reports of a problem moving files in the Leopard Finder. If you’re saying to yourself, […]

[…] qualche giorno circola in rete una notizia secondo cui il Finder di Leopard sarebbe affetto da un bug, a causa del quale sarebbe […]

[…] detalhes no artigo completo de Krazit e no relato original de Karpik. […]

[…] da robertodacci su 7 Novembre 2007 Da qualche giorno circola in rete una notizia secondo cui il Finder di Leopard sarebbe affetto da un bug, a causa del quale sarebbe […]

[…] Tom Karpik na swoim blogu przedstawia dokładnie swoje doświadczenia z tym bugiem. Po raz pierwszy ujawnił się on podczas przenoszenia plików za pomocą Samby na komputer sieciowy z FreeBSD. Potem okazało się, że problem jest generyczny i dotyczy kopiowania do dowolnej lokalizacji (również na innej partycji tego samego dysku). […]

[…] Tom Karpik writes: 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. […]

Have you never heard of http://bugreport.apple.com rather than showing your dirty laundry in public?

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

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!!

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.

[…] gros, le Finder de Tigrou Leopard contient un joli bug dans le code qui gère le déplacement des répertoires, ce qui peut entrainer des pertes massives de données, notamment lorsque vous transférez des […]

[…] You can read the original article from Tom here: Massive data loss bug in Leopard. […]

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.

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.

[…] Un resoconto dettagliato di questa disfunzione del codice di Leopard è stato pubblicato sul sito tomkarpik.com dove si riporta anche una dimostrazione pratica con un server […]

@zimmie: are you nuts?

[…] yet to Mac OS X 10.5 Leopard cropped up earlier this week with Tom Karpik’s blog warning of a Massive Data Loss Bug in Leopard. It seems that if you Move (not Copy) files to another disk or network volume, all of your data may […]

[…] be it a local USB drive, local Firewire drive, or SMB volume. On his website, Karpik has posted step-by-step instructions on how to reproduce glitch as well as a video demonstrating its affect. Leopard data loss […]

[…] sebebiyle büyük veri kayıpları meydana gelebiliyor. Haberi bir Mac OS X Leopard kullanıcısı weblogunda […]

[…] Tom Karpik explains more in this blog post. This is a must read for every Mac owner who has updated. addthisurl = ‘http%3A%2F%2Frobzpage.com%2Fblog%2F%3Fp%3D60′; addthistitle = ‘Bugs+already+in+Leopard%3F+Shame+on+you+Apple%21′; addthis_pub = ”; […]

Gravatar

Loweded Wookie

November 7th, 2007

What happened if you did a Command Z to undo?

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

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!

Gravatar

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.

sigh

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.

Yes, some massive speculation on check out the facts at rixstep.com see this: http://rixstep.com/1/1/20071106,00.shtml

[…] I was moving a directory from my desktop over to a Samba mount on my FreeBSD server. Read More at Tom Karpik’s Blog Tags: Massive+Data+Loss+Bug+in+Leopard, leopard, Tom+karpik, Bug, […]

Gravatar

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.

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

Correct.

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