Data Loss Bug In OS X 10.5 Leopard 603
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."
Tiger has this problem as well!!! (Score:5, Informative)
Terrible bug (Score:3, Informative)
Knowing it exists means you can also work around it by doing copies every time and only manually deleting the source entry when you're sure the copy has completed properly. Now all you need to do is be mindful every time you want to move a file anywhere.
Sucks to be a Mac user (I am one, I know) but I'm sure Apple will have this fixed pretty quick.
Par for the course? (Score:5, Informative)
For all of the flack the Windows file copy interface gets, it is both safer and more flexible than trying to use the Finder: an interface that makes file management so stupefying it becomes impossible.
Re:That's silly. (Score:5, Informative)
Re:That's silly. (Score:5, Informative)
Re:Par for the course? (Score:3, Informative)
Pax isn't an OS X tool [oreilly.com] tool any more than tar is - just an FYI. Also, learn to love rsync. It would've done what you described in a breeze (at least when compared with other command-line tools).
Re:That's silly. (Score:3, Informative)
Re:That's silly. (Score:5, Informative)
Typically if you are moving within the same logical device the file pointer is moved and no copying need take place.
When moving to another device your code reads and writes, within a loop and traps exceptions (such as the device suddenly vanished, where the OS should raise an exception and your application traps it.) A wide variety of errors could occur while moving and in the event any of them happen the user should be notified in an appropriate manner and the original data not deleted.
I've written a number of applications which moved files or data between databases and it's fundamental your application is on the watch for any problems. Not to have an exception raised or to trap any and all, well, that's simply an inexcusable lapse.
This sort of thing is extremely critical if you happend to be defragmenting a disk drive. Long before Macs and PCs we had to defrag our mainframe drives and the applications which did the work were quite careful. Often the best practice, if you had the resource of a second drive, was to simply defrag to a new drive then re-assign the new dist as the original.
Not default behavior (Score:4, Informative)
Re:I don't understand (Score:5, Informative)
Uhh no. In linux mv's always make sure the data moved then delete the original file (as far back as 2.4). You can test this by dd'ing a large file (use if=/dev/urandom), then run a md5sum on it, then do a mv within the same drive, over nfs, over samba/cifs, to floppy (not sure what happens here because linux caches writes to floppies until umount), to usb drive, whatever. While the mv is in operation just pull the plug on the system (target or source system). Your old file will still be there!
Re:No it isn't (Score:5, Informative)
Wrong-o!! You absolutely do not have to pay anything to involved in the Appleseed program.
Not just 10.5 (Score:2, Informative)
Re:Ah, the "outsourcing" coding model.. (Score:5, Informative)
The syntax for "||" is:
If command 1 fails, do command 2 - otherwise exit (where you used "command1 || command2").
In this case, your command will either copy all the files from $from to $to or delete all files at $from.
What you probably meant is cp $from $to && rm -r $from, which only performs the second command if the first succeeded. This solution is far from perfect for reasons mentioned by other posters, but it's still significantly safer and more useful than yours...
Re:"haha" (Score:2, Informative)
File The Bug!! (Score:4, Informative)
Re:Data deletion in Mac OS X (Score:3, Informative)
Re:Par for the course? (Score:5, Informative)
Serious answer...
XP offers a basic, do you want to replace folder and a basic do you want to replace files. (Very generic, but more than OS X does)
Vista on the other hand, asks if you want to replace/merge folder and then if conflicting files are found in the folders it asks you if you want to overwrite the files, don't overwrite them, or create a second copy of the file in the same folder. File by File and Folder by Folder if you want, or you can hit a check box to mimic your response for all file and folders if you are moving a lot of files/folders.
It also will show you the two versions of the file or folder so you can make a decision based on which files/folders are newer, and you even get a thumbnail of the file for documents and pictures to be sure you are keeping the one you want.
(Very simple interface, but more has the functionality of the power geek that was always left to using tools like XCopy in the past.)
This is one of the 'little' Vista features that doesn't get any press, but is a lifesaver for people that move around a lot of data, as you can merge and update folders and files much easier.
Stuff like this is the reason I said if MS did a 'new features' list like the pety list Apple did with their 300 new features, Vista would have several thousand new features to list.
(Again MS's marketing sucks, since most people don't even know stuff like this exists in Vista, and it is both powerful, easy, and just works.)
Re:I don't understand (Score:3, Informative)
Have you ever used a computer? Youre quite simply wrong. Ive had many move operations fail and never lost a file doing it. You can test by moving a large file, pulling the network cable out. The file is still on your PC. With your "bad disk" example, well yeah if the disk lies to the OS saying that files are copied when theyre not then that could happen. This would be very rare as bad disks tend to advertise rather loudly (to the OS) that they are going bad.
Re:I don't understand (Score:1, Informative)
In fact if you use verbose mode with mv you can see exactly what it's doing and it doesn't delete the old file until it confirms the new version was successfully copied. This is for volume-to-volume transfers, a move on the same volume is instantaneous and generally can not fail for most file systems (ext, xfs, etc).
I had this happening to me with WinXP aswell (Score:5, Informative)
(Or maybe Samba has something to do with it?)
Re:Terrible bug (Score:4, Informative)
Error code 51 doesnt neccesarily mean the transfer failed. It can also mean lost connection to the share - which could have happened (in OSX's "mind") after it thought/was told the transfer was complete.
For instance, what if in stopping the share on the Windows session (incorrectly listed in the /. article as a FreeBSD Share), the SMB crap in Windows is "cleaning up" while shutting down and generating a "complete" code that it sends back to the Apple machine, which then in trying to communicate with the share, realizes it no longer can, and generates the correct error code as noted (51).
OSX did NOT generate a disk write error or any other error that would have been more applicable (like 43 or a bunch of other possibilities). It generated an error stating it lost communication with the other machine.
Again, still not enough info without knowing more about what the WinShare does when closed.
Re:That's silly. (Score:3, Informative)
You have to be using 2.6.0 on both ends too.
Re:That's silly. (Score:3, Informative)
Re:Problems (Score:3, Informative)
Re:Or [possibly], go fix it. (Score:5, Informative)
Re:Ah, the "outsourcing" coding model.. (Score:3, Informative)
cp -aRp "$from" "$to" && rm -r "$from"
Re:That's silly. (Score:5, Informative)
- A dialog appears with the title Moving... and it says it's calculating how much time it'll take. This took a while itself.
- Then the dialog says it's moving the files and the progress meter shows the progress
- After the progress meter fills up, it goes to empty again and then says it's deleting the files it moved
I did this with most of the folders until I reached one that had about 18GB of data in it. I performed the same procedure as above to start the move and after it was copying files for about a minute or two I realized that I was moving them to the wrong location (my desktop instead of a directory on my C drive). At work our desktops are retargeted to a file server and not our local hard drives. I knew that by copying to the desktop I would hit my quota limit on the server whereas if I had copied to the C drive like I did with the other folders I had no limit aside from the free hard drive space. Not copying there in the first place was just a mistake. I clicked cancel to stop the transfer. When I did that, the dialog that had the progress bar changed to the empty progress bar and said it was now deleting. By the time I realized what was going on, it had deleted that folder and all of its content from the FTP site.Now this could have been some weird bug or interaction between the fact that I was using a machine with SP1 instead of SP2, that my desktop and profile were retargeted to another machine, or that I was moving so much data. It wasn't a lot of files as these were data files for desktop publish programs for some brochures and catalogs, along with large print-ready images. I don't know what items worked together to cause the problem. I do know that it did happen and that I had to deal with the IT group at our other site (that had the Solaris server), open the helpdesk ticket to get them to restore the files from backup, wait for them to get around to it, etc. It was a huge pain and delayed what I was working on, causing grief for myself and my internal customer. One thing's for sure; I'll never use the built-in Windows FTP client again.
Re:No it isn't (Score:3, Informative)
https://appleseed.apple.com/cgi-bin/WebObjects/SeedPortal.woa/wa/faq [apple.com]
OR, there's:
http://developer.apple.com/products/select.html [apple.com]Re:That's silly. (Score:5, Informative)
Re:Terrible bug (Score:4, Informative)
osx ? (Score:3, Informative)
This may not get read, but still (Score:4, Informative)
http://www.macintouch.com [macintouch.com] Obviously this is the front page story today.
This only affects "move" operations between logical volumes. You have to hold down Command while you're doing this, inside the Finder, to get this to happen. Yes, it's a bad bug. It's not something, however, that you're going to run into if you're thinking sensibly about how you treat important data, or if you didn't know that the Command-drag functionality was built into the Finder (which I didn't, and I can't think of a time when I would use it now that I do, even if it was working correctly).
Re:No it isn't (Score:3, Informative)
FYI the kernel has a syscall called rename which only works if both source and destination are on the same file system. If they are not, it fails and sets errno to EXDEV. Moves between file systems are simulated by userland programs doing a copy then a delete. I'm pretty sure that cp issues a rename and then falls back to copy-delete if it gets EXDEV back. The Finder must already know that the destination is on a different file system because default behaviour is to copy when a file is dragged onto a different file system and move iif it is dragged onto the same file system.