Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > Software - Troubleshooting and Discussion > Mac OS X > Massive Data Loss Bug in Leopard

Massive Data Loss Bug in Leopard
Thread Tools
Mac Elite
Join Date: Sep 2005
Status: Offline
Reply With Quote
Nov 5, 2007, 01:36 PM
 
I wrote a fairly detailed article about it on my site (here: tomkarpik.com Massive Data Loss Bug in Leopard), but the gist of it is basically ...

1. Initiate move operation across volumes
2. Destroy the destination while the move is in operation (ie. disconnect the SMB mount, unplug the USB device, etc.)
3. Finder *deletes* the source anyway, even though the move was not successfully completed
     
Professional Poster
Join Date: Jun 2007
Status: Offline
Reply With Quote
Nov 5, 2007, 02:35 PM
 
Interesting bug.

Personally I don't do moves, especially if its a large folder. I do a copy and then delete the source but then I'm paranoid
     
Senior User
Join Date: Mar 2002
Location: CT
Status: Offline
Reply With Quote
Nov 5, 2007, 02:41 PM
 
I filled a radar bug referencing your article.
     
Clinically Insane
Join Date: Oct 2000
Location: Los Angeles
Status: Offline
Reply With Quote
Nov 5, 2007, 02:47 PM
 
Pretty cool. I do moves all the time (only local drives though), and I'd be pissed if this happened to me. I guess it's a really good thing Leopard has Time Machine.

"The natural progress of things is for liberty to yield and government to gain ground." TJ
     
Tomchu  (op)
Mac Elite
Join Date: Sep 2005
Status: Offline
Reply With Quote
Nov 5, 2007, 08:21 PM
 
Originally Posted by Chris Grande View Post
I filled a radar bug referencing your article.
Thanks!
     
Senior User
Join Date: Nov 2005
Status: Offline
Reply With Quote
Nov 5, 2007, 08:27 PM
 
You made Slashdot too...

Slashdot | Data Loss Bug In OS X 10.5 Leopard

I have to admit that I'm quite surprised by this...I would think that a move would make sure stuff was moved before deleting the source. Maybe this is why when you drag and drop between volumes, the default action is a "copy" and not "move."
     
Professional Poster
Join Date: Nov 2004
Location: eating kernel
Status: Offline
Reply With Quote
Nov 5, 2007, 08:33 PM
 
Originally Posted by frdmfghtr View Post
You made Slashdot too...

Slashdot | Data Loss Bug In OS X 10.5 Leopard

I have to admit that I'm quite surprised by this...I would think that a move would make sure stuff was moved before deleting the source. Maybe this is why when you drag and drop between volumes, the default action is a "copy" and not "move."
Digg too
Signature depreciated.
     
Tomchu  (op)
Mac Elite
Join Date: Sep 2005
Status: Offline
Reply With Quote
Nov 5, 2007, 09:19 PM
 
Yeah, I submitted my story to Digg, but I didn't expect Slashdot to pick it up. Cool.
     
Professional Poster
Join Date: Nov 2000
Location: Tasmania, Australia
Status: Offline
Reply With Quote
Nov 5, 2007, 09:30 PM
 
This is a feature, not a bug. It is a means for Apple to promote the use of Time Machine.
     
Forum Regular
Join Date: Feb 2007
Status: Offline
Reply With Quote
Nov 5, 2007, 09:45 PM
 
Good to know, hope you didn't lose anything that wasn't backed up.
     
Addicted to MacNN
Join Date: Oct 2002
Location: England | San Francisco
Status: Offline
Reply With Quote
Nov 6, 2007, 04:32 AM
 
can we keep bug discussions in one thread?
Thanks.


Edit: you know, second thoughts - I think this is a critical enough bug for it to be separate from the "general niggles with Leopard"
( Last edited by Peter; Nov 6, 2007 at 08:39 AM. )
we don't have time to stop for gas
     
Fresh-Faced Recruit
Join Date: Nov 2007
Status: Offline
Reply With Quote
Nov 6, 2007, 04:13 PM
 
Can anyone check if this is true with other move methods as well?
I.e. Tom showed this problem with drag-n-drop,
what about cut-paste?
or mv from the terminal?
Using the same/similar scenario: e.g. Moving a large folder to a USB stick and pulling it out mid-transfer.

edit:
nm about the mv command, I just checked the man page, and it specifically states the copy-check-delete step as the process by which mv works
     
Professional Poster
Join Date: Nov 2004
Location: eating kernel
Status: Offline
Reply With Quote
Nov 6, 2007, 04:27 PM
 
Originally Posted by ninjit View Post
Can anyone check if this is true with other move methods as well?
I.e. Tom showed this problem with drag-n-drop,
what about cut-paste?
or mv from the terminal?
Using the same/similar scenario: e.g. Moving a large folder to a USB stick and pulling it out mid-transfer.

edit:
nm about the mv command, I just checked the man page, and it specifically states the copy-check-delete step as the process by which mv works
There is no cut and pasting of files in Leopard, or Mac OS X for that matter...
Signature depreciated.
     
Tomchu  (op)
Mac Elite
Join Date: Sep 2005
Status: Offline
Reply With Quote
Nov 6, 2007, 04:30 PM
 
Since the bug is really in the Finder's handling of a move op, the "mv" program (Terminal) is not affected. It does its own logic, as you just discovered. :-P
     
Fresh-Faced Recruit
Join Date: Nov 2007
Status: Offline
Reply With Quote
Nov 6, 2007, 07:43 PM
 
Originally Posted by C.A.T.S. CEO View Post
There is no cut and pasting of files in Leopard, or Mac OS X for that matter...
I could have sworn there was one , but apparently not since 10.0 has cut-paste been allowed in the Finder....
     
Addicted to MacNN
Join Date: Oct 2002
Location: England | San Francisco
Status: Offline
Reply With Quote
Nov 7, 2007, 05:34 AM
 
cut and paste is a terrible idea for file management.
What if you cut a file, then copy a piece of text - where have your files gone?
we don't have time to stop for gas
     
Tomchu  (op)
Mac Elite
Join Date: Sep 2005
Status: Offline
Reply With Quote
Nov 7, 2007, 11:22 AM
 
Originally Posted by Peter View Post
cut and paste is a terrible idea for file management.
What if you cut a file, then copy a piece of text - where have your files gone?
This is the #1 mis-conception about cutting/pasting of files. Let's clear it up:

a) When files are "cut", they aren't read or moved anywhere. References to these files are simply stored in memory (the clipboard). When you then perform a "paste" operation, the OS goes back and moves these files, because it has a list of names.

b) If one were to put something new in the clipboard while some files are in a "cut" state, the references to the files are simply overwritten with your new data. The files go back to a normal state.

c) Anyone who's ever used Windows knows that when you "cut" files, their icons become semi-transparent, but the files themselves go nowhere.

d) It would be completely retarded to read every file that's been "cut" into memory and then delete the file off the hard drive. Not only does this risk your data the moment you do another CTRL+C, but it would also take huge amounts of time and memory.

Windows' cut and paste mechanism for files is sound, and a pleasure to use.
     
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status: Offline
Reply With Quote
Nov 7, 2007, 11:58 AM
 
Originally Posted by Tomchu View Post
Windows' cut and paste mechanism for files is sound, and a pleasure to use.
And terribly confusing to new users.

It might make more sense to call it something other than "cut and paste" when dealing with files.

Maybe "pick up and drop?" "Pick up and move?" Something else?
     
Tomchu  (op)
Mac Elite
Join Date: Sep 2005
Status: Offline
Reply With Quote
Nov 7, 2007, 02:13 PM
 
Perhaps.

Though I've never met any new users who weren't able to apply the "cut and paste" concept to files after learning about its use on text.
     
Mac Elite
Join Date: Jan 2006
Status: Offline
Reply With Quote
Nov 7, 2007, 02:29 PM
 
I finally installed Leopard after holding back for a couple of weeks to read everyone's experiences. I must be fortunate because I haven't encountered a single problem so far (except that Stacks is crap) and all my apps work. My workflow is untouched.
     
Professional Poster
Join Date: Feb 2007
Location: T •
Status: Offline
Reply With Quote
Nov 7, 2007, 03:14 PM
 
Apple should really have addressed this by now.
     
Senior User
Join Date: Mar 2002
Location: CT
Status: Offline
Reply With Quote
Nov 7, 2007, 11:06 PM
 
Well they closed mine as a duplicate, so it goes.
     
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Nov 7, 2007, 11:24 PM
 
Originally Posted by Tomchu View Post
This is the #1 mis-conception about cutting/pasting of files. Let's clear it up:

a) When files are "cut", they aren't read or moved anywhere. References to these files are simply stored in memory (the clipboard). When you then perform a "paste" operation, the OS goes back and moves these files, because it has a list of names.

b) If one were to put something new in the clipboard while some files are in a "cut" state, the references to the files are simply overwritten with your new data. The files go back to a normal state.

c) Anyone who's ever used Windows knows that when you "cut" files, their icons become semi-transparent, but the files themselves go nowhere.

d) It would be completely retarded to read every file that's been "cut" into memory and then delete the file off the hard drive. Not only does this risk your data the moment you do another CTRL+C, but it would also take huge amounts of time and memory.

Windows' cut and paste mechanism for files is sound, and a pleasure to use.
Yes, we know that. And the problem with that is that what is happening there is not a cut and paste. It doesn't behave the way cut-and-paste is supposed to, it doesn't behave the way a user would expect cut-and-paste to work, and therefore it is a mislabeled feature and an inconsistency in the interface.

MS's design philosophy there seems to have been "If it walks like a duck, and quacks like a duck, call it a hamster."

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
Tomchu  (op)
Mac Elite
Join Date: Sep 2005
Status: Offline
Reply With Quote
Nov 8, 2007, 12:07 AM
 
Explain.

Remember that you're talking file context, not text context. Files can't simply be made to "disappear" when cut. That would be a terrible design decision (and on par with Apple's "move" bug).
     
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Nov 8, 2007, 01:34 AM
 
Which is why they should be called something other than "cut" and "paste". Cutting a file in Windows does not do what the "cut" operation is supposed to do.

There are other problems, too. If you cut something (or copy something - Apple's guilty of this one too), it puts the contents of the item as of the time of the cut/copy operation on the pasteboard. When you paste, you get the same data you copied, regardless of whether the original has changed since the cut/copy operation. That also doesn't work with the Windows cut/paste files feature.

This is what interface consistency is about (not scroll bar color, as some people seem to think). Functions like cut and paste that have clearly defined behaviors shouldn't act differently in every separate app. If that happens, it breaks the cut/paste metaphor and makes its function unpredictable.

This also applies to Excel, by the way.

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
Tomchu  (op)
Mac Elite
Join Date: Sep 2005
Status: Offline
Reply With Quote
Nov 8, 2007, 03:00 AM
 
Originally Posted by CharlesS View Post
There are other problems, too. If you cut something (or copy something - Apple's guilty of this one too), it puts the contents of the item as of the time of the cut/copy operation on the pasteboard. When you paste, you get the same data you copied, regardless of whether the original has changed since the cut/copy operation. That also doesn't work with the Windows cut/paste files feature.
You really have no idea what you're talking about, do you? I want you to get on a Windows machine and try this.

I'm not even going to get into the myriad of technical reasons for why such a "cut" feature is basically not feasible. You still fail to understand how "cut" works in Windows.
     
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Nov 8, 2007, 03:25 AM
 
Originally Posted by Tomchu View Post
You really have no idea what you're talking about, do you? I want you to get on a Windows machine and try this.
So what you're telling me then, is that Windows copies the entire file into memory when you cut/copy it, so that if you make a change in between the cut/copy operation and the paste operation, the file that gets pasted will be the original, and not the file with modifications? This I doubt.

I'm not even going to get into the myriad of technical reasons for why such a "cut" feature is basically not feasible.
Well I know that, although you don't seem to, given your previous quoted statement. The issue is that if the feature they have is not actually a "cut" feature, then it shouldn't be called "cut". The "cut" feature doesn't do anything resembling a cut at all. It just marks a file for moving. If you change the original file before pasting, it will just move or copy the file at paste time, so what gets pasted will include all your changes. So you could copy a file, replace the entire contents of the file with completely new data, paste, and end up with a file completely unlike the file you copied. This is not how cut/copy and paste works. When you cut or copy something - and I mean actually cut or copy it - it copies it to the pasteboard. Then, no matter how much you modify the original data, what you paste will be exactly what you copied. This does not work in Windows Explorer.

You still fail to understand how "cut" works in Windows.
I know how "cut" works in Windows very well, thank you.
( Last edited by CharlesS; Nov 8, 2007 at 03:45 AM. )

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
Posting Junkie
Join Date: Nov 2000
Location: in front of my Mac
Status: Offline
Reply With Quote
Nov 8, 2007, 03:40 AM
 
Cut on Windows doesn't cut. However, once you paste something you actually haven't cut, it gets moved. The whole Explorer Cut&Paste doesn't behave like C&P everywhere else in the UI. It doesn't do what it says. Bottom line: it's confusing and bad UI. End of story.

If MS would have done it right, they would have called it something like "Note for Move" and "Move here". Sounds cheesy? Yeah of course, but at least it now says what it does. I am not disputing that it's a very fast way to move files for geeks who understand what they are doing; of course they'd be better of with CLI mv in the first place. For everybody Explorer else C&P it's a confusing mess.
     
Tomchu  (op)
Mac Elite
Join Date: Sep 2005
Status: Offline
Reply With Quote
Nov 8, 2007, 04:55 AM
 
Originally Posted by CharlesS View Post
So what you're telling me then, is that Windows copies the entire file into memory when you cut/copy it, so that if you make a change in between the cut/copy operation and the paste operation, the file that gets pasted will be the original, and not the file with modifications? This I doubt.
Err, no. I believe that is what *you* were saying above. ;-) Unless it was just badly-written ...

The semantics of what it should be called are irrelevant. The fact stands that it's a safe feature, and a very handy one at that.
     
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status: Offline
Reply With Quote
Nov 8, 2007, 08:26 AM
 
Originally Posted by Tomchu View Post
The semantics of what it should be called are irrelevant. The fact stands that it's a safe feature, and a very handy one at that.
I don't think anyone is debating the feature itself. It is quite safe, and it is handy to have. Nobody is disputing that, but the "semantics of what it should be called" ARE relevant.
     
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Nov 8, 2007, 11:47 AM
 
Originally Posted by Tomchu View Post
Err, no. I believe that is what *you* were saying above. ;-) Unless it was just badly-written ...
Or unless you have a reading comprehension problem. Read it again - I was talking about how C&P works, and how what Windows does with files doesn't qualify. Every one of my posts on the topic so far has been about interface consistency, not about anything being dangerous, and I think that's been quite obvious to anyone who doesn't have this burning need to dismiss all criticism of this feature by pretending that people just don't understand how it works.

If it walks like a duck, and quacks like a duck, don't call it a hamster.
( Last edited by CharlesS; Nov 8, 2007 at 11:54 AM. )

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
Banned
Join Date: Jun 2003
Status: Offline
Reply With Quote
Nov 8, 2007, 11:55 AM
 
I think CharlesS was clear in his wording, Tomchu. You misunderstood what CharlesS was saying about cut and paste. He was merely explaining how cut and paste is supposed to work and how Windows' cut and paste in Explorer is some completely different concept of marking a file for move. Cutting another file in Explorer before pasting the previously cut file won't erase the previously cut file...yet in any other application if you cut text or an image or whatever and you don't paste it anywhere and you proceed to cut some other element, you lose the previously cut text/image/whatever and the only way to get it back is with undo. Explorer's cut and paste is a hack...one that is supposedly intuitive considering the amount of whining I hear about Mac OS not allowing cut and pastes in the Finder. But it's a hack nonetheless because it's behavior is different in Explorer and one would expect the file to disappear when cut...not be marked for move.

edit: Perhaps Microsoft is on to something though...perhaps the better behavior is marking the element. Explorer does this but maybe, just maybe, this behavior should be transposed to the universal cut and paste actions. In a word processor cutting a sentence should perhaps mark it in case the user decides to cut something else. This would piss off users that use Cut as a delete but Cut shouldn't be seen as a delete action anyway but rather as a displacement. This change would be hard for a lot of people to swallow though...it would throw away everything that users have known about Cut and Paste for the last 30 years. Then again...maybe it wouldn't be so bad considering a lot of people are familiar with this way of cutting and pasting in Windows.
( Last edited by Horsepoo!!!; Nov 8, 2007 at 12:09 PM. )
     
Professional Poster
Join Date: Jun 2007
Status: Offline
Reply With Quote
Nov 8, 2007, 01:57 PM
 
Originally Posted by Tomchu View Post
Though I've never met any new users who weren't able to apply the "cut and paste" concept to files after learning about its use on text.
Agreed and I as so many other people who work on the window's platform finds it incredibly useful. I wish apple would employ this type of mechanism.

I understand it does not fit in the Human Interface Guidelines but still, it is very useful and makes moving files a whole lot easier.

I don't know any user, new or a grizzled veteran not to use this "feature", and I have not found anyone confused by this. My users are probably the least technology savvy people around, i.e., they ask me how to do a screen print (hint there's a key on the keyboard that says print scrn) yet they fully grasp the concept of cutting/pasting files.
     
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status: Offline
Reply With Quote
Nov 8, 2007, 02:57 PM
 
Originally Posted by MacosNerd View Post
I don't know any user, new or a grizzled veteran not to use this "feature", and I have not found anyone confused by this.
Well, I must be the first you've met to not use the feature. I've been an Apple user since 1984 when I had my Apple IIc, and a Windows user since Windows 3.11, and I've never cut/pasted a file. Ever. And I probably never will, and I use XP and Vista daily alongside Leopard. But I'll always prefer the Mac OS.

But I agree that it is a useful function. We're not arguing usefulness. We're arguing what it should be called, and if it were to come to the Mac, it wouldn't be called "cut and paste," it would be called something closer to what it's really doing. But it would work exactly as it does on Windows.
     
Fresh-Faced Recruit
Join Date: Sep 2007
Status: Offline
Reply With Quote
Nov 12, 2007, 02:05 AM
 
With text or pictures in a file, cut-and-paste moves text or picture from one location to another. In Windows, cut-and-paste moves the file from one location to another. Hey, what do you know?
     
Posting Junkie
Join Date: Nov 2000
Location: in front of my Mac
Status: Offline
Reply With Quote
Nov 12, 2007, 03:03 AM
 
Originally Posted by pt123 View Post
With text or pictures in a file, cut-and-paste moves text or picture from one location to another. In Windows, cut-and-paste moves the file from one location to another. Hey, what do you know?
Riiiiiight, nice try.

In Windows: cut removes the text or picture. Don't paste it and it's forever gone. Cut a file and nothing happens. It's only marked for move. Don't paste it and nothing happens.

Great consistency there.

Hey, what do you know?
     
JKT
Professional Poster
Join Date: Jan 2002
Location: London, UK
Status: Offline
Reply With Quote
Nov 12, 2007, 07:59 AM
 
Originally Posted by MacosNerd View Post
I don't know any user, new or a grizzled veteran not to use this "feature", and I have not found anyone confused by this. My users are probably the least technology savvy people around, i.e., they ask me how to do a screen print (hint there's a key on the keyboard that says print scrn) yet they fully grasp the concept of cutting/pasting files.
Of course you don't - there is a blindingly obvious reason why as well... to try and move any files in Windows by any other means is an exercise in extreme frustration. You are practically forced to use "cut" and paste in Windows because trying anything else is a royal PITA.
     
Banned
Join Date: Jun 2003
Status: Offline
Reply With Quote
Nov 12, 2007, 08:15 AM
 
Anyway, it doesn't really matter since moving files (using cut and paste or dragging files from one place to another) is an antiquated behavior. If you still do it, perhaps you should still be using Mac OS 9 or Mac OS X 10.3 at the latest...I mean, why would you need a modern OS if you're still doing the same thing you were doing back in 1984!

Spatial file managers, specific locations for files...these are all things of the past. I have no pity for people whining about the Finder not having cut and paste. Put your documents in the Documents folder and put your applications in the Application folder, use Spotlight and shut up!
     
Fresh-Faced Recruit
Join Date: Sep 2007
Status: Offline
Reply With Quote
Nov 12, 2007, 10:06 AM
 
Originally Posted by JKT View Post
Of course you don't - there is a blindingly obvious reason why as well... to try and move any files in Windows by any other means is an exercise in extreme frustration. You are practically forced to use "cut" and paste in Windows because trying anything else is a royal PITA.
Consistency? Oh like Time Machine where you click the + to "omit" backing up a file, doh.
     
Grizzled Veteran
Join Date: Mar 2004
Status: Offline
Reply With Quote
Nov 12, 2007, 10:20 AM
 
Originally Posted by JKT View Post
Of course you don't - there is a blindingly obvious reason why as well... to try and move any files in Windows by any other means is an exercise in extreme frustration. You are practically forced to use "cut" and paste in Windows because trying anything else is a royal PITA.
 
Not a Windows user myself, but I've always suspected that was the case.

I'll be interested to see how MacosNerd and Tomchu respond to that... unless
of course, they'd rather avoid it.
-HI-
     
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Nov 12, 2007, 11:56 AM
 
Originally Posted by Horsepoo!!! View Post
Spatial file managers, specific locations for files...these are all things of the past. I have no pity for people whining about the Finder not having cut and paste. Put your documents in the Documents folder and put your applications in the Application folder, use Spotlight and shut up!
That's what I used to do, but now that Stacks have messed up my ability to have my Documents folder in the Dock when it contains a few hundred items, it's starting to look like I'm going to have to organize it......

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
Senior User
Join Date: Nov 2005
Status: Offline
Reply With Quote
Nov 12, 2007, 05:25 PM
 
On the topic of the bug, it appears that 10.5.1 is going to address it...

AppleInsider | Latest Mac OS X 10.5.1 build fixes Finder data loss issue

It will be interesting to see how it is fixed, if this is the case.

Look at what you started Tomchu! (Good show!)
     
   
Thread Tools
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Top
Privacy Policy
All times are GMT -4. The time now is 02:01 PM.
All contents of these forums © 1995-2015 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.8 © 2000-2015, Jelsoft Enterprises Ltd., Content Relevant URLs by vBSEO 3.3.2