Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Data Loss Bug In OS X 10.5 Leopard

Posted by kdawson on Mon Nov 05, 2007 07:33 PM
from the first-do-no-harm dept.
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."
+ -
story

Related Stories

This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • by ackthpt (218170) * on Monday November 05 2007, @07:36PM (#21248189) Homepage Journal

    Normally while moving you ensure the copy completed before deleting the original. Apple must be using some discount programmers.

    • by eniac42 (1144799) on Monday November 05 2007, @07:53PM (#21248409) Journal
      Advert on Amazon Mechanical Turk:
      Write OS-X compatible application to Move a file between two filesystem devices..
      Time Allotted:: 6 hours. Reward: $10.00..
    • Apple must be using some discount programmers

      Of course not! Don't be a troll.

      Everyone knows that Apple's products Just Work, and that's no different in this case. The files were moved just like you asked, and if you can't find them. well, that's not Apple's fault, is it? You don't blame the contractor who built you home when you lose your keys, do you?

      In any case, you should be using Shadow Copy...er...Time Machine which would have protected you from going and losing track of your own files.
      • Re:That's silly. (Score:5, Informative)

        by ackthpt (218170) * on Monday November 05 2007, @08:19PM (#21248739) Homepage Journal

        So what happens if you're moving a 120GB folder one directory level on a 150GB disk?

        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.

  • by itsybitsy (149808) on Monday November 05 2007, @07:36PM (#21248191)
    I lost a huge amount of data being MOVED (not copied) from one volume into a virtual volume DMG file. Lost and gone forever, lots of important files. What happened? I simply bumped the laptop Mac Book Pro during the move... zap... gone forever. The DMG file was blank! Yes, complely zero bytes except for a bit of header non-file data. It sucks bad.

    • by Chouonsoku (1009817) on Monday November 05 2007, @07:40PM (#21248237) Homepage
      Just wanted to also confirm that the bug was in Tiger. I was backing up music files to do a clean format for Leopard and lost everything when the hard drive got disconnected by mistake.
        • by Liquidrage (640463) on Monday November 05 2007, @07:54PM (#21248427)
          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.
      • So your irreplaceable videos were made the previous year and you had no backup.

        I suppose the PC makers should like you. You'll shoot up a PC and have to buy a new one every couple years. And each maker will get a piece of the action, since you'll blame the previous maker for routine data loss.

        Or you could just do what everyone in the computer business has been telling you to do for at least 30 years and... make a backup.

  • by juanfgs (922455) on Monday November 05 2007, @07:42PM (#21248275) Homepage
    This is the new Leopard "iLostMyFrigginFiles" feature, next version they will add a badass black hole effect when it does that!
  • Par for the course? (Score:5, Informative)

    by GoRK (10018) <johnl@blurbcoHORSE.com minus herbivore> on Monday November 05 2007, @07:45PM (#21248311) Homepage Journal
    No offense meant here, but normal move/copy operations are traditionally highly destructive events on MacOS anyway. For instance there is absolutely no simple way to merge two folders contents together on the mac. If you drag a folder called "Documents" into your home directory and click on "OK", the Mac OS will happily delete your entire documents folder. I was reminded of this enormous frustration while recovering from some multi-volume backups recently, having to resort to an obscure OS X commandline tool 'pax' and Leopard's newfound support of hardlinks to make some simple file copies play nice and not unnecessarily consume 3 times the disk space they should have.

    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.
    • by Blakey Rat (99501) on Monday November 05 2007, @08:04PM (#21248553)
      That's left over from the original spatial Finder design in Mac Classic. Apple hasn't really decided whether they want to get rid of the spatial interface, so instead they've made this horrible frankenstein half-spatial, half-browser interface which pretty much everybody hates.

      Doing a "replace" for that operation makes sense in a spatial system because all spatial icons are treated the same way. You'd wouldn't expect dragging a Word file named "happy.doc" into a folder already containing a "happy.doc" to perform a merge operation; so why would you expect that with a folder in the same situation?

      That said, if you've never used Mac Classic, you'd think OS X has nothing but a browser interface, in which case all metaphors and ideals are out the damned window, and the OS might as well do a merge operation. Since you most likely came from Windows, or a Linux environment ripped-off from Linux, you'd expect dragging identically-named folders together to do a merge operation because that's what you're used to.

      Apple needs to make up its mind what Finder is. It gets worse and worse every version.
    • by nine-times (778537) <nine.times@gmail.com> on Monday November 05 2007, @08:09PM (#21248635) Homepage

      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.

      • by JunoonX (1171445) on Monday November 05 2007, @08:07PM (#21248607)
        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.
  • Wow (Score:5, Interesting)

    by Zebra_X (13249) on Monday November 05 2007, @07:52PM (#21248393)
    Unbelieveable. Forgot to check the result of the copy operation eh? So basically this is a catastropic defect for people who deal with very large media files to and from remote stores or people who deal with virtual machine images.

    Back in the day when I used to use my mac I dropped a directory (A) into another directory (B) but there was an existing directory (C) with the same name as (A). The finder asked me something, I clicked OK. I was dismayed to find that the dialog had asked me "Would you like to replace directory C, with A?" - Why on earth would that ever be the default option for a directory move? From the users perspective you aren't really moving the directory, the intention is to move the files, thus the sane response would be to merge A with C not replace it.

    Whatever.
  • "haha" (Score:5, Interesting)

    by MutantEnemy (545783) on Monday November 05 2007, @08:31PM (#21248879) Homepage

    Why is every destructive computer bug that happens tagged with "haha"?

    Data Loss Bug In OS X 10.5 Leopard
    bug, macosx, apple, haha

    Symantec Updates Cause Chaos in China
    haha, security, bug, windows, feature

    Banner Ad on Myspace Serves Adware to 1 Million
    haha, myspace, pwnd, security, adware

    Ubuntu May Be Killing Your Laptop's Hard Drive
    linux, haha, storage, bug, spam

    Islamists exploit buffer overflow, hack U.S. nuclear command; world doomed
    eschaton, religion, waronterror, haha

    OK, I made one of those up. But it doesn't even matter what OS or company is responsible for the problem - whoever makes the tags seems to take great delight in all computer snafus. How does the tagging system work anyway? It's always been mysterious to me.

    • Wait... (Score:5, Funny)

      by ackthpt (218170) * on Monday November 05 2007, @07:40PM (#21248241) Homepage Journal

      It's kind of strange that this didn't come up while people were beta testing OS X 10.5. Samba is used in many places. I hope they get it fixed soon.

      Exactly which decade did you fall into your recently awkened from coma in? Testing? Testing? Nobody tests anything anymore, they just go play with all the new toys and stare at the eye-candy. Actual mundane, humdrum testing? That's an SEP if ever I didn't see one.

    • Re:Wierd (Score:5, Funny)

      by cnettel (836611) on Monday November 05 2007, @07:40PM (#21248253)
      All fanboys were just happy with how blazing fast file copy was compared to Vista. The non-fanboys tried to check the real size of the dir by copying it to a Vista machine afterwards, but the progress bar got stuck on 413 hours left and counting, so they couldn't file the bug in time.
    • Re:Terrible bug (Score:5, Insightful)

      by Liquidrage (640463) on Monday November 05 2007, @07:43PM (#21248281)
      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.
      • Re:Terrible bug (Score:5, Insightful)

        by Knara (9377) on Monday November 05 2007, @08:11PM (#21248653)

        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?