Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Bug Businesses OS X Operating Systems Apple

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."
This discussion has been archived. No new comments can be posted.

Data Loss Bug In OS X 10.5 Leopard

Comments Filter:
  • by ackthpt ( 218170 ) * on Monday November 05, 2007 @06: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 @06: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..
    • by nmb3000 ( 741169 ) on Monday November 05, 2007 @07:00PM (#21248499) Journal
      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.
      • by Roger W Moore ( 538166 ) on Monday November 05, 2007 @09:59PM (#21250203) Journal
        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.

        Great! So now not only don't we know where our data is but when it is. Perhaps in a week or two's time the data will materialize in the folder it was supposed to be moved to with an accompanying "whorping" sound coming from the speakers?
    • Re: (Score:3, Funny)

      by Eq 7-2521 ( 159354 )
      No, it's probably just that the automated Schnapps IV system [xkcd.com] that they have for maintaining the Ballmer Peak went awry one day. (Read the tooltip if you haven't seen this before.)
  • by itsybitsy ( 149808 ) on Monday November 05, 2007 @06: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 syylk ( 538519 ) on Monday November 05, 2007 @06:38PM (#21248223) Homepage
    ...As if millions of fanboys suddenly cried out in terror and were suddenly silenced.
  • Terrible bug (Score:3, Informative)

    by thegrassyknowl ( 762218 ) on Monday November 05, 2007 @06:39PM (#21248231)
    But entirely fixable.

    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.
    • Re:Terrible bug (Score:5, Insightful)

      by Liquidrage ( 640463 ) on Monday November 05, 2007 @06: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: (Score:3, Interesting)

      Another thought springs to mind... 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?

      I haven't "upgraded" yet so I don't actually know much about this Time Machine thing and how it works.
      • Re:Terrible bug (Score:5, Insightful)

        by Knara ( 9377 ) on Monday November 05, 2007 @07: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?

      • Re:Terrible bug (Score:5, Insightful)

        by TheNetAvenger ( 624455 ) on Monday November 05, 2007 @08:02PM (#21249207)
        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.
        • by megaduck ( 250895 ) <{dvarvel} {at} {hotmail.com}> on Monday November 05, 2007 @10:48PM (#21250541) Journal
          Speaking as one of those IT people, NTFS is probably one of the coolest pieces of software ever to come out of Redmond. ACLs, alternate data streams, directory junctions, single-instance stores, shadow copy, the list of useful features is huge. Even more surprisingly, it works pretty much as advertised. Frickin' cool.

          There's another angle, though. On paper, Vista's NTFS-based backup technology walks all over Time Machine. However, the USABILITY of Vista's technology is crap. This morning, I enabled Time Machine by plugging in a USB drive and clicking "Use as Backup Disk" when prompted. To do restores, I launch the cleverly named "Time Machine" application. I've already used it twice today just because it's fun to watch the spacey animations.

          Compare that to Vista's clunky "Backup and Restore Center", which you have to use if you want to backup your files on an alternate volume. I guarantee you that using "Backup and Restore Center" is beyond most average users. Sure, it might be "better", but what good is it if it never gets used?
        • Re:Terrible bug (Score:4, Informative)

          by Pliep ( 880962 ) on Tuesday November 06, 2007 @05:46AM (#21252747) Homepage
          Actually, Time Machine runs every two minutes. You can see a countdown timer in the system preferences. Also, Time Machine is dodgy by itself. Apple confirms that after backing up about 10 GB of data, Time Machine may stop working. See here: http://docs.info.apple.com/article.html?artnum=306932 [apple.com]
    • Re:Terrible bug (Score:4, Interesting)

      by El Lobo ( 994537 ) on Monday November 05, 2007 @07:00PM (#21248507)

      but I'm sure Apple will have this fixed pretty quick.
      Well, the problem is, this bug exists even in TIGER and has been repported many times! And no, not fixed yet. Abble is a coorporation like any other, and not the superpower that some users seem to think they are.
  • by juanfgs ( 922455 ) on Monday November 05, 2007 @06:42PM (#21248275)
    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 ) on Monday November 05, 2007 @06: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 @07: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 mctk ( 840035 ) on Monday November 05, 2007 @07:27PM (#21248843) Homepage
        or a Linux environment ripped-off from Linux

        Forking Linux developers!
      • Re: (Score:3, Interesting)

        Simple solution: Change the dialog that pops up and says, "[Cancel] [Replace]" to one that says"[Cancel] [Replace] [Merge]". Done.
      • Re: (Score:3, Insightful)

        by Tim C ( 15259 )

        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?

        Because folders are containers. To use a real-world analogy, it's perfectly possible to take the paper out of a folder and put it in another, rather than to throw out the original folder and put the new one in its place.

        Of course, it's also perfectly possible to have identically-labelled pieces of paper in

    • by nine-times ( 778537 ) <nine.times@gmail.com> on Monday November 05, 2007 @07: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.

      • Re: (Score:3, Interesting)

        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.

        I guess the reason I have a problem with this is that my own computer usually has 3 drive letters listed - the internal hard drive, an external hard drive, and my USB flash drive, which I plug in when I sign on, usually
    • Re: (Score:3, Informative)

      by Just Some Guy ( 3352 )

      having to resort to an obscure OS X commandline tool 'pax'

      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).

    • by node 3 ( 115640 ) on Monday November 05, 2007 @07:20PM (#21248765)

      For instance there is absolutely no simple way to merge two folders contents together on the mac.
      Open a folder, "Select All", drag into destination folder.

      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.
      It does state this is going to happen in the window with the OK button.

      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.
      If you were going with the command line, you could have just used "cp" or "rsync". Your mention of hardlinks is perplexing, though. OS X has supported hard links forever. It recently added support for hard linking folders (extending hard links beyond the standard). Since you're comparing with Windows, does Windows somehow know if you are copying a file that's identical to one that already exists, and makes a hard link? I'm fairly sure it doesn't.

      For all of the flack the Windows file copy interface gets, it is both safer and more flexible than trying to use the Finder
      How so? This bug aside, I don't see how it's safer *or* more flexible. The difference--the *only* difference--here is whether folders replace or merge. Windows isn't more flexible, as it does one way, not both. As for safer, they both tell you when something destructive is going to happen.

      the Finder: an interface that makes file management so stupefying it becomes impossible.
      Impossible? Really? All because it replaces folders (and tells you, with a chance to abort) instead of merging them?
  • by tji ( 74570 ) on Monday November 05, 2007 @06:49PM (#21248363)

    Not to be glib, but.. This would be a great demonstration of the value of "Time Machine" backups. Time Machine is not perfect, but it is a good start on a backup system well integrated into the OS. The example problem, data loss, would be really easily recovered via Time Machine.

    Beyond the basics that every decent backup app does, the things I like about Time Machine are:

    - Integration into Applications. For example: "Show me what my iTunes library or iPhoto library looked like last Thursday"

    - Integration into OS install. In the case of disk failure, recovery to previous state is simple - rather than multi-step with a separate backup app.

    Some things that need improving:

    - Better handling of file exceptions. I keep work data in encrypted disk volumes (DMGs). If I change one byte, the whole huge file needs to be backed up as each change is detected (generating MANY copies of that big DMG). The only other choice is to say "ignore this file/directory". Same thing applies to any large file, such as a VMware VM file. A better option would be to say "Back this file up, but only keep 'n' versions".

    - Time Machine has gotten twice, pegging the CPU/fans on my MacBook Pro.
  • Wow (Score:5, Interesting)

    by Zebra_X ( 13249 ) on Monday November 05, 2007 @06: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.
    • Re: (Score:3, Insightful)

      by Tack ( 4642 )

      I was curious, so I tried this scenario with Nautilus (the file manager in GNOME). It prompted me: "A folder named 'A' already exists. Do you want to replace it?" which sounds rather much like the Mac OS behavior your described. But it goes onto explain: "The folder already exists in 'B'. Replacing it will overwrite any files in the folder that conflict with the files being copied." This suggests instead that unlike the dialog heading, B/A will not be replaced, but the two directories' files merged. I

  • Thread bug? (Score:3, Insightful)

    by mveloso ( 325617 ) on Monday November 05, 2007 @07:20PM (#21248761)
    This may be a bug in the Finder thread code. Why?

    Think about it: safe data movement has been around since filesystems existed. However, the new Finder is multi-threaded. It could be that the error handler is doing the wrong thing with the thrown exception...after all, what -do- you do with an exception in a subthread? What mechanism do you use to throw it upwards to the parent thread?

    That's the joy of error handling, which is totally separate (though completely integral) to your normal architecture issues.
  • by GaryPatterson ( 852699 ) on Monday November 05, 2007 @07:28PM (#21248849)
    Okay, this is a terrible bug, but to me the real news is that the Finder has a move operation. I've only ever used the simple drag (ie copy) when transferring files to other disks. That might also be why I've never had this disconnection-delete problem.

    The workaround is trivial - copy files until you're certain. In fact, I'd recommend doing that in all OSs anyway. Moves or cut-pastes are fraught with potential badness. I've lost files in Windows doing that, and always wondered what's wrong with just moving and deleting manually later on.
  • "haha" (Score:5, Interesting)

    by MutantEnemy ( 545783 ) on Monday November 05, 2007 @07: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.

  • Not default behavior (Score:4, Informative)

    by Have Blue ( 616 ) on Monday November 05, 2007 @07:42PM (#21248999) Homepage
    Someone should point out that by default, the Finder will copy files dragged to a different volume. You have to hold down a modifier (Command) to force a move operation. So while this is a severe bug that should be fixed immediately, it's much less likely to happen by accident than the article implies.
  • by ChrisA90278 ( 905188 ) on Monday November 05, 2007 @09:07PM (#21249803)
    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.
    • by Cantus ( 582758 ) on Tuesday November 06, 2007 @12:43AM (#21251321)
      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.
  • by Lisandro ( 799651 ) on Monday November 05, 2007 @09:08PM (#21249805)
    That's it, moving a file, network failure and poof, moved files deleted from the source. Most probably a bizarre coincidence, but after it happened a few times i now copy and then delete when working on a SMB network.

    (Or maybe Samba has something to do with it?)
  • osx ? (Score:3, Informative)

    by l3v1 ( 787564 ) on Tuesday November 06, 2007 @06:35AM (#21252931)
    I don't think this is an OSX specific bug. Just this weekend I moved some video files over from a Windows desktop pc to my also Windows media pc (Windows based custom box) to a shared folder, then I went out for a tea, came back in, and I forgot the move was in process, and I switched off the media pc. About half an hour later I went back to my desktop pc, to see an error message about a failed write, then all the files I wanted to move have been deleted from the desktop pc. Checking the media pc, the first file was there, but damaged.

  • by master_p ( 608214 ) on Tuesday November 06, 2007 @07:51AM (#21253257)
    First of all, files should never be deleted, they should only be hidden, unless the disk is full, of course.

    Secondly, "move" across different devices should be copy and then delete.

    Thirdly, if you copy a folder over another one with the same name, the computer should ask you what the purpose is: merge or replace? merge is often as catastrophic as replace if merging results in undesirable file combinations.

    Forthly, files should be versioned by the O/S, as in VMS. It was a great feature, I don't know why it's missing from all modern O/Ses.
  • by analog_line ( 465182 ) on Tuesday November 06, 2007 @09:50AM (#21254259)
    This is a bug with the FINDER ONLY, just so everyone is clear. The Unix "mv" command in Leopard is NOT affected by this.

    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).

//GO.SYSIN DD *, DOODAH, DOODAH

Working...