[Tomchu]

I wrote a fairly detailed article about it on my site (here: [defunct]), 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

[MacosNerd]

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

[Chris Grande]

I filled a radar bug referencing your article.

[Big Mac]

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.

[Tomchu]

Originally Posted by Chris Grande 

I filled a radar bug referencing your article.

Thanks!

[frdmfghtr]

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

[C.A.T.S. CEO]

Originally Posted by frdmfghtr 

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

[Tomchu]

Yeah, I submitted my story to Digg, but I didn't expect Slashdot to pick it up. Cool.

[Brass]

This is a feature, not a bug. It is a means for Apple to promote the use of Time Machine.

[~bash $]

Good to know, hope you didn't lose anything that wasn't backed up.

[Peter]

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"

[ninjit]

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

[C.A.T.S. CEO]

Originally Posted by ninjit 

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

[Tomchu]

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

[ninjit]

Originally Posted by C.A.T.S. CEO 

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

[Peter]

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?

[Tomchu]

Originally Posted by Peter 

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.

[Person Man]

Originally Posted by Tomchu 

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]

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.

[PaperNotes]

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.

[analogue SPRINKLES]

Apple should really have addressed this by now.

[Chris Grande]

Well they closed mine as a duplicate, so it goes.

[CharlesS]

Originally Posted by Tomchu 

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

[Tomchu]

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

[CharlesS]

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.

[Tomchu]

Originally Posted by CharlesS 

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.

[CharlesS]

Originally Posted by Tomchu 

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.

[Simon]

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]

Originally Posted by CharlesS 

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.

[Person Man]

Originally Posted by Tomchu 

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.

[CharlesS]

Originally Posted by Tomchu 

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.

[Horsepoo!!!]

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.

[MacosNerd]

Originally Posted by Tomchu 

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.

[Person Man]

Originally Posted by MacosNerd 

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.

[pt123]

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?

[Simon]

Originally Posted by pt123 

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]

Originally Posted by MacosNerd 

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.

[Horsepoo!!!]

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!

[pt123]

Originally Posted by JKT 

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.

[Hal Itosis]

Originally Posted by JKT 

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.

[CharlesS]

Originally Posted by Horsepoo!!! 

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

[frdmfghtr]

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