Leopard data loss glitch uncovered A blogger has uncovered what he claims is a "massive" bug in Apple's Mac OS X 10.5 Finder app that could result in the loss of data when folders are moved from a Mac to directly- or network-connected storage. According to Tom Karpik, the bug manifests itself when an attempt to move - rather than copy - a folder from the Mac is …
If this is a known bug that has been around since version 10.3, why has it not been fixed? It always astounds me the blind loyalty that Apple users have, willing to forgive or forget the software failings, ignore bad hardware design flaws while still spouting how great Apple are. They are the first ones to jump on any MS failings while forgetting that MS cater for a much larger user base on any conceivable hardware configuration. Apple don't have that excuse and should be ashamed.
@ Joe: It's would be somewhat iironic if it *did* exist with *copy*... unfortunately this is a bug with *move*... (AKA cut+paste)
@ Danny: Stop being astounded.... this is how the world goes round. If you like/follow one product, company, football team, country, dictator/president/prime minister, then this is clearly how people naturally present things from their viewpoint!! It's not astounding or even surprising, it's just what you'd expect. If Windows does something stupid, I'm going to ridicule Microsoft, if OSX does something stupid I'm going to sympathise with Apple users, if Linux does something stupid, I'll prove that it's designed that way or user error ;) So I'm prejudiced. Sue me. Our prejudice is what separates us from the animals :p
Are you claiming that Windows is any better? I don't own a Mac. I do use XP. I've had to resort to using XCOPY from the command line for any serious copying because Windows Explorer is so unreliable.
OS religious wars aside: if I were grading "Programming 101" assignments, anyone who deleted the source without first attempting to verify the copy would lose half the available marks automatically.
Historically, I seem to recall that OSes used to copy then verify but some marketing twat realised that this took twice as long so they cut the verify bit and claimed their system was faster. Combine that with clueless morons doing the purchasing and thereafter everyone else had no choice but to follow suit and we have the crap that we have today.
As I am using Tiger and regularly use this method to copy files from my Mac to my NAS with a flaky wireless router, it's never once nuked any data.
Check your facts @ Jeff Paffett.
This will be a good reason for me to hold off on the upgrade to Leopard though as it's one of the things I do automatically, I could easily black hole alot of data.
Or maybe this is more of a reflection that it's a bug that doesn't really affect users that much - as El Reg's article (and a hardly uncritical one) points out.
Sounds quite a big bug to me myself, but it's hardly one that has been flooding sites like Macintouch and Macfixit, which are excellent for covering technical flaws.
I would say it never ceases to astound me that any story that's critical of Apple will be accompanied by posts bleating about how stupidly and blindly loyal Mac users are - but it doesn't surprise me in the least. Those sort of comments say much more about the poster that who they're posting about.
Any OS that looses it's network connection or suffers a power outage while moving data will lose the data or corrupt it.
Only the uninitiated or masochists or Apple FUDists would do such a thing and then whine that the OS didn't save them from their stupidity.
And to think that these whiners are bloggers who presumably know better. No doubt, there's some mighty Apple FUD being stirred up in the blogosphere. These FUD creationist have nothing to hold up against Apple except these inane scenarios.
"Any OS that looses it's network connection or suffers a power outage while moving data will lose the data or corrupt it."
Wrong.
Neither Windows nor Linux or any other correctly written OS will delete the source file being moved until the file has copied completely to the destination.
Try it yourself - create a file, try moving it and pull the power out during the file transfer, the next time you boot up your source file will still be there and the destination file will either be partially complete or automatically deleted.
with moving a file to network drives.
I think Windows uses an asynchronous write* (delayed write in MS speak): while the file is still being transferred, the PC end of the link says the file has been written, and the PC will delete it from the PC drive. Meanwhile, the link fails and only part of the file is written to the server's drive by the server.
* http://en.wikipedia.org/wiki/Asynchronous_I/O
Not really async writes are never performed on the root drive of a windows server box, I think the issue here is more to do with the crappy coders at apple as in
CopyFile
DeleteFile
instead of
CopyFile
If not failed then VerifyFIle
If failed then
DeleteCopiedFIle
else
DeleteOriginalFile
I blame Jobs for interupting his developers to piss about on iPhone when they have more important things to be doing, typical managers pissing around.
If this bug has been around since OS X 10.3 Panther, then it can't be as serious as some people are making out, since in those 4 years or so only the original person who discovered the bug and this Mr. Karpik have experienced it.
I usually move lots of my files around and I've never had suffered data loss.
>Neither Windows nor Linux or any other correctly written OS will delete the source
>file being moved until the file has copied completely to the destination.
Oh yes it will. It's happened to me many many times with flash drives and Windows. Hence why I always copy and never move.
The default behaviour in all versions of Mac OS when dragging files between volumes is to *copy* files (i.e. leave the originals in place), not move them (i.e. copy to the target and then delete the source).
I'm fairly sure this dates back to the Finder that shipped with the Mac 128K in the mid 80s.
Most Mac users would drag the file onto another volume and then delete the original afterward to make space on the source drive.
If true, it's not a pretty bug, but the number of people who even know that you can Command-drag and move (delete the originals) still less those who use it regularly, must be fairly small. The subset of those who actually encounter the bug and suffer data loss must be tiny.
... you disconnect the other storage during the move? Errr, well, why did you do that? What kind of twat pulls the plug on storage while any kind of operation on it is in progress? I wouldn't do it on Windows or Linux let alone OS X. Never mind lose the file, you're likely to corrupt the drive format or file allocation tables.
Next up why use Move at all? Earlier this year I walked in to the beginnings of an SBS server migration project (it had been going one day) where the outsource decided to move rather than copy the data files between the two system. They did it wrong. Messed up directories. Lost files. It took four days to recover the mess while showing them the outer side of the front door. And thats the so-called professionals, so what hope does the average numptie stand.
There is always going to be someone, somewhere, who can "break" any OS so lets not get our knickers too wet at the prospect of finding such a so-called flaw in OS X.
So there is a bug in OS X is there? Big f*****g deal.
No there isn't A bug in OSX. If you have noticed since its release there are MANY MANY bugs. When this happens with Windows, you lot are the first to start shouting about how crap MS are, don't be surprised that when Apple release a piece of shit like this you get jumped all over in return, Especially after a 6 month delay. If it wasn't ready, they shouldn't have shipped it. It doesn't matter that they already have 10.5.1 in line to fix these bugs, if this was a MS thread it would be full of comments such as 'never touch it til the 1st service pack' and 'bloody MS shipping something this buggy and plan to fix it as they go along, why do we always have to be their testers' etc
But the roughly equivalent Windows (Vista) version of this bug was a show stopper - taking too long to copy, move or delete files over a network. This bug you just have to make sure you copy a file rather than move one over a network - OK, it is a waste of your time having waiting for the copy to finish, so the source file can be deleted.
I'm no particular Mac OS X fan or Windows hater (except when it ruins my day :)
Both Windows and Mac OS X seem to show a lack of network robustness, you can forgive Windows as it is only a PC DOS extended to network, the surprise is that Mac OS X with its NEXTSTEP roots is not.
Hey, wow, so it could happen!
To put it bluntly, anyone who moves - as against copies - a folder from one drive to another (including network storage) is risking disaster. File corruption can happen at any point and invisibly - as I found out to my cost recently - so anyone who loses information due to moving rather than copying loses my sympathy as well as their data.
It may be a 'bug' but it's one I would never, ever encounter because I am not that stupid.
See you on the dark side... Windows that is.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
