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?
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.
Apple charges good money for Leopard, so let them fix it.
The default Finder behavior when you drag a file from one volume to another is to copy the file. To do a move you press the Command key and drag the file to its new destination.
The second you drop the file, it begins copying the file to the destination volume, but the original file disappears... poof, gone. If you stop the move operation, you're left with an incomplete file in the destination volume and with nothing in the original volume. This is to me a major bug.
This is why, for large files, I always copy.