Slashdot Mirror
Data Loss Bug In OS X 10.5 Leopard
An anonymous reader 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 progress. This author first came across it when Samba crashed while he was moving a directory from his desktop over to a Samba mount on his FreeBSD server."
Yes, that's easily avoidable. If you know it exists. And hopefully the first time you get bitten by this it isn't something critical. Would be garbage to have to work around that one.
TFA looked decent in it's details. Even step by step recreation. But it's a pretty serious bug, that as you mention, *needs* to be fixed quick and I didn't see any other sources confirming it.
Can't agree with you. It is the exact type of that is usually caught by automated testing. The issue isn't that a hard drive was bumped. The issue is that the write operation failed. In this case due to a drive no longer being accessible. The failure is easily automated, and the result of that failure is easy to catch.
And I wouldn't exactly call this regression testing, as such functions as file movement aren't usually impacted by later changes. It should be pretty basic on the design chart. Sounds to me more like "working as intended...use move at your own risk". Which I think it stupid, but I don't see how this really was *missed*, especially since some are claiming it's been this way since at least Tiger.
When two folders, both named "Documents", where one is dragged and dropped into the home directory containing another "Documents" folder, Windows prompts if you want to replace content from the dropped folder on to the one being dropped on. At this point, if any files with same name are encountered, they will be replaced with the one from the first directory; however, all other files in folder will stay intact.
If you drag a folder called "Documents" into your home directory and click on "OK",
To be fair, I don't think it asks you whether it's ok to move that directory. It will warn you that it's going to replace that folder, and the buttons will either say, "Replace" or "Stop". It's not that ambiguous.
The only thing that makes it problematic is if you're accustomed to working in a file manager that will automatically merge directories, then you might think it's going to merge when it's actually going to replace. I would say that neither behavior is "wrong", but you certainly can get unhappy results if you're expecting one behavior and get another.
Honestly, it took me a little while to get used to it, but now that I expect it, it's fine. Usually, if I'm doing anything complicated with copying/moving lots of stuff recursively, I'm going to want to use a command line anyhow. In the command-line, "cp" and "mv" work in normal unix fashion.
You're asking if a bug wherein entire folder hierarchies can go *poof* in the event a network share drops should be considered critical? Are you serious?
If it's true that Apple's products seem less-tested these days, it's because they've tossed lots of seasoned customer quality-assurance testers to the wayside.
Many years ago, think System 7, Apple had this great Customer Quality Feedback (CQF) program. We tortured our systems between the alpha-testers and the great unwashed masses. There were Apple staff who (gasp) listened to our bug reports and got back to us reasonably quickly. It was grand.
Then someone got fired, or promoted, or whatever, and the CQF program got lost in the shuffle. Every few years I get an email from someone at Apple telling me that they're reconstituting it, but nothing ever comes of it, and - you know - it's hard to understand how they can ignore a free, highly-motivated bunch of fanboys.
I was born not knowing and have had only a little time to change that here and there. -- Richard Feynman
Reeducate the user, you say. Surely you must be joking, right?
Let's ignore for a moment that Leopard may have a few bugs that will have to be ironed out. That's only to be expected with *_any_* newly released OS and the reason why no sane person would ever dare to update the OS on a mission critical machine within the first few months of the release.
However, if you can't rely on your OS to perform a simple file move without risking data corruption, then the right solution is definitely not to verify every single operation by hand. Automating tedious tasks is exactly what computers do best, and that the OS ensures the integrity of the copy before throwing away the original is definitely something you should expect.
is this even that critical? Doesn't leopard have the time machine in it? Can't you just go back and get your files out of the time machine if they were that important?
Only if a backup of the files was run, which is a requirement of Time Machine.
If this was Vista, then there would be a good chance to use 'previous versions' to recover the folder data, as it does not 'solely' rely on external backup for timeline file recovery. Vistas use volume level file version snapshots(a feature of NTFS that HPS+ doesn't support), so there are backups even on the drive if it hasn't ever been backed up.
(Remember Time Machine usually only runs once an hour, and all versioning or changes made in that hour are never kept or tracked.)
-PS Not trying to troll, but this is a perfect example of the difference between Vista's previous versions and Apple's Time Machine I have tried to point out in the past.
Vista does both volume level backups and external backups, unlike just external backups like Time Machine does.
See why IT people prefer Vista's method, even if a backup hasn't run that hour, even users themseleves can access files and folders rather easily that got deleted or changed. And since this has been around Since Windows 2003 Server, in corporate environments, even XP users accessing 2003 servers have had this feature for over 4 years now.
Vista's claim to fame is that it enables these features on the local hard drive, and also integrates with the Vista backup system, so file versions appear from the backups in addition to the 'snapshot versions' on the main hard drive.
Did you miss the part where Leopard reported an error on the copy? (No, really... I'm not being snarky, did you actually miss that screenshot?) Leopard correctly recognized that the transfer had failed, and still deleted the source.
To me, that's a pretty clear bug. What stuns me is that Apple isn't using the underlying "mv" command - since it should certainly deal with this situation. They rolled their own defective version.
Never re-invent the wheel. You'll have a square wheel with 13 lug nuts of all different sizes. Just go to Goodyear and take the tried-and-true.
--Somebody infect me with a
There's absolutely no reason that a modern "move" command shouldn't already be implementing the exact process you've just described, no matter where it is moving to.
There is a good chance the disk drive or the networked computer is giving the finder an "OK I got it" signal BEFORE the data is actually written to the physical disk drive. So it gives this signal, then the finder deletes the old data and then the disk drive "goes away" before the data is written out of the cache and to the drive. Don't blame Finder, blame those huge disk caches where many megabytes sit and wait to be written to the drive.
If this is true then the bug is im the copy of Samba running on the file server. We do not yet have enough information to know.
Apple charges good money for Leopard, so let them fix it.
Not exactly. The Leopard finder is doing something like: like in "remove $from regardless if the copy was successful or not".