Data Loss Bug In OS X 10.5 Leopard

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

Comments

That's silly.

[ackthpt]

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

Re:That's silly.

[DJ Rubbie]

Which is why I normally cp -a to the destination if it's on a different partition within the computer or over the network, then validate the content on the other side (if I need to) before removing files from origin. If a move was used, and then later found the data on the other end isn't exact, there's nothing to do but either attempt to recover original file or restore from backups. This applies to any OS, as a power failures happening to both machines could compromise data integrity.

Granted, this is not what current generation of typical user would do, but I believe they should be educated on this anyway.

Re:That's silly.

[Hatta]

Why don't you just use rsync?

Re:That's silly.

[nmb3000]

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.

[Eq 7-2521]

No, it's probably just that the automated Schnapps IV system that they have for maintaining the Ballmer Peak went awry one day. (Read the tooltip if you haven't seen this before.)

Re:That's silly.

[Frothy Walrus]

Oh yeah, rsync. Is that one still broken on 10.5? Apple's build of rsync on 10.4 consistently choked on a few files when my dad started using it on his Mac Pro.

Re:That's silly.

[vought]

Normally while moving you ensure the copy completed before deleting the original. Apple must be using some discount programmers. So what happens if you're moving a 120GB folder one directory level on a 150GB disk?

Re:That's silly.

[doxology]

then some metadata on the disk is modified to reflect your move.

Re:That's silly.

[ackthpt]

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.

Re:That's silly.

[Anonymous Coward]

Then you twiddle inodes and the data itself never even gets looked at.

Duh.

Re:That's silly.

[Anonymous Coward]

duh. You just move the location of the folder in the directory tree. This comment, after applying a minimal amount of brain power, is obviously alluding to moving from one volume to another; the same type of move that if affected by this move.

Re:That's silly.

[vought]

then some metadata on the disk is modified to reflect your move. That's what I thought; the synopsis of the article seems to confuse the copy and move operations. I always considered a "move" to be traversing the directory tree of a particular volume, but the submitter is actually talking about a copy operation between two volumes, not a file move on a single volume...

Re:That's silly.

[Taagehornet]

this is not what current generation of typical user would do, but I believe they should be educated on this anyway

Reeducate the user, you say. Surely you must be joking, right?

Let's ignore for a moment that Leopard may have a few bugs that will have to be ironed out. That's only to be expected with *_any_* newly released OS and the reason why no sane person would ever dare to update the OS on a mission critical machine within the first few months of the release.

However, if you can't rely on your OS to perform a simple file move without risking data corruption, then the right solution is definitely not to verify every single operation by hand. Automating tedious tasks is exactly what computers do best, and that the OS ensures the integrity of the copy before throwing away the original is definitely something you should expect.

Re:That's silly.

[Edward Teach]

I am telling you, I am being a very talented programmer. I am working on the Apple, it is finder program and I am telling you, I am being very talented.
</IndianAccent>

Re:That's silly.

[Anonymous Coward]

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. That work anything like NetApp's Snaphot technology??

Re:That's silly.

[kc2keo]

Strongly agree with you. Anytime I have a file to copy over a network connection I never move the file otherwise should a failure occur like a power failure the original copy on the source machine is intact then you just recopy it to the destination host machine. Then delete it afterwards from the source machine if you want to.

Re:That's silly.

[Ian Alexander]

Oh yeah, rsync. Is that one still broken on 10.5? Apple's build of rsync on 10.4 consistently choked on a few files when my dad started using it on his Mac Pro. Is there something preventing you from just building it yourself?

Re:That's silly.

[spud603]

In TFA, the distinction is made between a move on a single volume and a move between volumes. No confusion.

Re:That's silly.

[porkchop_d_clown]

Does the open source version support resource forks? That's the main reason for using Apple's. If I knew I could use the stock version, I would.

Re:That's silly.

[Matt Perry]

I ran into this same problem in Windows XP. I was moving files from a FTP server to a local directory. When moving files from an FTP server, Windows first copies all of the files and then once the copy is complete it deletes them from the FTP server. Well, I just started the copy and realized that I was copying the files into the wrong directory. So I clicked "Cancel" and Windows stopped moving the files... Then it deleted all of the files from the FTP server.

Ouch.

Re:That's silly.

[Anonymous Coward]

Yup. Good thing the Apple OS has come with an Undelete tool since the early eigh... wait, what?

Re:That's silly.

[linuxtelephony]

How about a critical resource starvation issue on the Mac when rsync. I used rsync to move LOTS of data between a mac and various linux machines. At least, I did until it started dumping tons of errors. This also happened when I built rsync on the Mac, so the problem is some underlying library and I didn't have time to track it down.

End result, I stopped using the Mac and then sold it since it become more of a headache than it was worth to move data to/from it at that point.

This was around the time 10.4 was released (the problem affected both 10.3 and 10.4), and I don't remember the actual error message any longer. That wasn't the only oddity I encountered during the 6-9 months or so where the Mac was basically my only machine. Overall, I was less than impressed and quite disappointed. Oh well.

Re:That's silly.

[Anonymous Coward]

Not possible, clicking cancel will not complete the move and delete the original. Never seen it happen and have done that several times myself.

Re:That's silly.

[Anonymous Coward]

Won't necessarily work.

          Recently I used rsync to copy some files on my notebook before installing Ubuntu over the gentoo install that was on it. Well, the 2.6.23 kernel had an NFS corruption bug. (2.6.23-gentoo-r1 doesn't.) So I was rsync'ing to a machine that was then silently corrupting some files as it wrote them out.. nice. running rsync normally wouldn't catch this, the file size and time matched fine so it figured it was a good transfer. -c (checksum) flag will however.

          So, I would run it -c or run md5sum on both copies to make sure they actually match.

          rsync's broken in 10.4 and 10.5? Ouch, that sucks, I use rsync all the time.

Re:That's silly.

[Anonymous Coward]

I think you misunderstand something. Here, we're discussing a program (Leopard) deleting files on failed moves. I know for a fact that I've successfully canceled FTP-moves on Windows (brand); I also know for a fact that I've successfully canceled FTP-moves on all modern instances of the Windows OS with various FTP clients (programs). What program were you using that fragged your FTP server directory exactly? I suspect you're a fud-fucking idiot, although at the moment, I'm interested to hear if there's more than fabrication here. Pray tell: how can I reproduce this bug?

Re:That's silly.

[v1]

right now version 2.6.0 is the only one worth using. It still can't copy pipes, and isn't smart enough to set ownership on symbolic links, but it doesn't mangle anything else.

You have to be using 2.6.0 on both ends too.

Re:That's silly.

[FromellaSlob]

The super-safe way to do this on a Unix filesystem would be:

1. Create hard links for new locations.
2. Verify hard links were successfully created.
3. "Delete" files from the old locations, thus leaving the new hard links as the only pointers to the files.

Whether this approach is actually used much, I don't know.

Re:That's silly.

[passion]

You want the resource fork... from Apple's rsync manpage: -E --extended-attributes copy extended attributes, resource forks

Re:That's silly.

[777a]

Windows does something similar, but slightly more buggy.

Use the default Windows file manager to login to an FTP server, move a file, then cancel the move.

Windows deletes the partially moved from from your system, then sends the delete command to the server too.

Been like that since Internet Explorer 4 to at least Internet Explorer 6 (which was the last time I checked).

Re:That's silly.

[Anonymous Coward]

And if you need to move the files to a different volume, just use symbolic links instead of the hard links! Oh, wait...

Re:That's silly.

[vanyel]

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.

Except Time Machine doesn't work if you have File Vault turned on (an admittedly hard problem to solve), which eliminates the main reason I wanted to upgrade to Leopard.

This damn thing just bit me because I'd previewed some pictures on an sd card, then closed Preview and moved them onto my file server. Except for some reason it thought they were "still in use", causing the move to fail, taking the pictures with it. Fortunately not important ones.

Not too surprised, being essentially a .0 release, it's to be expected to be a beta tester...

Re:That's silly.

[Anonymous Coward]

What FTP program were you using? FTP download/uploads the file, then the FTP program will send a command to delete the original. This del command is handed off to the OS and the OS uses its native file system commands to delete the file. Sounds like your FTP application was jacked if it sending a del when the file was not fully transfered. Now... If you were using the cmd line FTP in XP or IE to do your transfers, it would still be the fault of MS but that is not the OS itself. By you hitting "cancel", it sounds like you were not using the cmd line version so either it was IE, Explorer, or a 3rd party FTP client. Is this repeatable? I'm not being a hater, just trying to see if this is a real problem or an isolated case where you have no idea what happened.

Re:That's silly.

[Matt Perry]

I think you misunderstand something.

No, I understand perfectly.

I know for a fact that I've successfully canceled FTP-moves on Windows (brand); I also know for a fact that I've successfully canceled FTP-moves on all modern instances of the Windows OS with various FTP clients (programs).

I'm not talking about other clients. I'm talking about using Windows XP as the client.

What program were you using that fragged your FTP server directory exactly?

Windows XP, service pack 1.

I suspect you're a fud-fucking idiot

You need to work on your social skills.

although at the moment, I'm interested to hear if there's more than fabrication here. Pray tell: how can I reproduce this bug?

You might need to use WinXP service pack 1. I'm unable to reproduce it now on my home machine which has SP2 installed. At work we've just upgraded to service pack 2 within the last six months. Anyway, about a year ago I was trying to move nearly 40 gigs of data from a Solaris server at another site to my local machine. The Solaris server was an FTP server and that's the only access I had to it. I opened Internet Explorer and typed in ftp://servername and was prompted for a username and password which I entered. Then I saw the files in the explorer view just like I see files on my local machine. Since I was moving so much data I decided to do it one top-level directory at a time. To move the files I selected the folder, dragged it to a folder on my local machine, and held down shift when I let go of the mouse pointer so it would move instead of copy. I noticed that Windows went through three steps when it moved from the FTP site:

1. A dialog appears with the title Moving... and it says it's calculating how much time it'll take. This took a while itself.
2. Then the dialog says it's moving the files and the progress meter shows the progress
3. 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:That's silly.

[networkBoy]

And if you need to move the files to a different volume, just use symbolic links instead of the hard links!
Oh, wait... That's right up there with what my brother did.
I jokingly told him to sudo rm -r -f /
he tried it...

I'll have to tell him to do the softlinks / delete the hardlinks as a way to um... shadow his files :-)
-nB

Re:That's silly.

[Skuld-Chan]

Isn't this a Mac? I thought they were supposed to be easy to use.

Re:That's silly.

[dave562]

However, if you can't rely on your OS to perform a simple file move without risking data corruption, then the right solution is definitely not to verify every single operation by hand.

On the contrary, that is exactly the thing to do. When you are working in mission critical environments and are charged with the safety of important data, it behooves you to do things the "slow way" sometimes for the simple reason that you have a safety net. In case of a disaster, it's much easier to restart a file copy than it is to pull data off of a backup tape because some of it got lost in the middle of a move operation.

Re:That's silly.

[Matt Perry]

See my response here: http://slashdot.org/comments.pl?sid=351141&cid=21251417

Re:That's silly.

[kisielk]

There have been resource fork patches for some time, but somewhat unreliable. Version 3.0 is going to support resource forks (and other types of extended attributes) out of the box. The setup we have been using extracts resource forks to a separate file on the mac and then backs them up alongside the original files. The restore process just performs the reverse. It will be nice once we can switch to rsync 3.0 and get rid of that step.

Re:That's silly.

[Wiseman1024]

I'd love to see the faces of those who spent $5000 on Apple stuff because it suits their metrosexual digital lifestyle when they lose their DRM-ridden files when copying them to their statutory iPod.

Re:That's silly.

[Anonymous Coward]

I think the thing to remember here is that you should probably be doing that in a mission critical environment regardless of whether your OS has a known bug or not. However, it's a big deal for the rest of us (ie Leopard's huge target audience as a desktop OS), we should be able to rely on it to do the right thing and take some of the tedium out of computing.

Verifying everything by hand is exactly the thing us normal people buy PCs to avoid. Why not go back to writing your letters by hand so you know everything is spelt right? Managing your money by hand so you know you can't be subject to any rounding errors? Hell, why not edit audio by using magnets directly on the magnetic tape? Yes, it's good to verify things every so often to make sure nothing is broken (and yes, I MD5 checksum my backups every so often to make sure nothing is dying), but I don't have to (and shouldn't have to) do it EVERY time I back up my files...

Re:That's silly.

[Anonymous Coward]

Reeducate the user, you say. Surely you must be joking, right?

I'm not joking, and don't call me Shirley.

Re:That's silly.

[ch0knuti]

One thing's for sure; I'll never use the built-in Windows FTP client again
And this is despite the fact that it happened only once and you haven't been able to reproduce it (the bug)? I think it is rather harsh isn't it? Even if it is windows we are talking about :)

Re:That's silly.

[delire]

resource fork... from Apple's rsync manpage: -E --extended-attributes copy extended attributes, resource forks

With cryptic commands just to copy files Apple will ALWAYS have ~.001% market share. When will Apple get it into their head that programmers shouldn't design user interfaces?

Why doesn't Apple just copy the way Ubuntu does it and get with the 2000's?

Pride is what it is. That damned pride!

Re:That's silly.

[the_lesser_gatsby]

A move is programmed as:

1. Copy the source file to the destination
2. Read the destination file back to ensure it's identical to the source file
3. Delete the source file

Rocket science it ain't (probably been patented though...). At what point in this process would a power failure lose your data? If your OS programs a move in any other way, run away.

Re:That's silly.

[Ultimate Statement]

The 4 rules of computing:
1. Make a backup
2. Make another backup
3. Check if your backups are working
4. Turn the thing off, and go out and have a life.

Re:That's silly.

[Anonymous Coward]

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. Thank you for saying this. I cannot count the number of fan boys who were like, "Look how cool and innovative Time Machine is." Microsoft does something and people scoff. Apple does it and gives it a "cool name" and you get innovation. Now, Microsoft wasn't even the first to do it, but hell, I wish people would wake up and realize everything that Apple does isn't instant innovation.

Re:That's silly.

[Lars T.]

No, this is a Mac - it makes it easy to run things that are supposed to be hard the way they are supposed to be, if you want to.

Re:That's silly.

[moranar]

I don't think they pay him to beta-test the Windows FTP functionality. I wouldn't use it anymore either, especially since you can get better ftp packages for free.

Re:That's silly.

[Wiseman1024]

Lol, I forgot you can't say anything wrong about Apple.

Though the good thing is that Apple metrosexual elitists who use a $5000 Mac as the central hub of their digital lifestyle burn their mod points in this, and their opinion counts less for important matters. So keep burning them.

Re:That's silly.

[chis101]

Is it really? Reading the destination file back after a write to a network drive could be very slow. I have a feeling that the OS simply says "It doesn't seem like anything went wrong" and then deletes the source file. What if you have a fat upload pipe, but the destination doesn't have much upload bandwidth? It could take forever to read back the file over the network to ensure integrity. It would be nice to have a verify option, but I do not believe it should be the default.

Re:That's silly.

[jo42]

Gupta, is that you?

Re:That's silly.

[cyber-dragon.net]

I have said this before and I shall say it again... apple does not get their reputation from inventing things... they get it from doing it RIGHT. To compare Time Machine, which integrates with and can be accessed from within applications themselves, or on individual folders to M$s system restore in which you wipe out your system to restore a single file is like saying a Pinto and a Ferrari are the same thing because they both have tires and a gas peddle.

Re:That's silly.

[the_lesser_gatsby]

You're not a programmer, are you? You'd have failed an interview with me, anyway. If you're gonna do something as drastic as deleting a source file, you'd better be sure the destination's there because you're gonna get bitten one day. Some would call it 'defensive programming' and it's the default for many developers.

BTW, how could a failed write (USB drive unplugged mid-move) be seen by the OS as "it doesn't seem like anything went wrong"?

Re:That's silly.

[Anonymous Coward]

>You might need to use WinXP service pack 1. I'm unable to reproduce it now on my home machine which has SP2 installed.

So you are comparing a OSX bug that repros in Nov. 2007 to a Windows XP bug fixed in XP SP2 (released Aug 2004), and the fact that was present on other OSes in the past justifies the poorly implemented feature? (yes, you weren't able to upgrade to sp2 but the fix was available nevertheless) Funny we don't see these types of justifications when a bug for non OSX OS is discovered.

>One thing's for sure; I'll never use the built-in Windows FTP client again.

I take it you'll never use OSX ever again as well?

Re:That's silly.

[Some_Llama]

I can relate, let me just say if you accidentally name a file * (especially if it is in the root directory) rename it to something else before trying to delete it.

Re:That's silly.

[idontgno]

Within a single filesystem, yes. This has been the basic function of the "mv" command since Ken Thompson was a wee sprout.

As is made painfully clear in TFA, and not so clear in the summary, this failure occurs in inter-FS moves. You know, the eternal "copy to new place, delete from old place" thing. The one that always has had an implied "delete from old place only if the copy to new place completed successfully." Which Apple somehow forgot.

Re:That's silly.

[graviplana]

/sigh. Not the old inaccurate-comparison-to-the-inferior-Microsoft-backup-that-isn't-like-Time-Machine-at-all-reference again. You'd think people would RTFM...oh wait...

Re:That's silly.

[Anonymous Coward]

Because rsync can't hard-link directories. Time Machine is rsync2007.

Re:That's silly.

[v1]

Apple didn't write Rsync. You must be new.

http://en.wikipedia.org/wiki/Rsync

Re:That's silly.

[Matt Perry]

So you are comparing a OSX bug that repros in Nov. 2007 to a Windows XP bug fixed in XP SP2 (released Aug 2004), and the fact that was present on other OSes in the past justifies the poorly implemented feature? (yes, you weren't able to upgrade to sp2 but the fix was available nevertheless) Funny we don't see these types of justifications when a bug for non OSX OS is discovered.

I'm not comparing or justifying anything. I was just telling a story.

I take it you'll never use OSX ever again as well?

What do you mean by again? I've never even seen OS X much less used it. The last time I used a Mac was around the 1998-1999 timeframe when I owned a PowerComputing machine with MacOS 8.

Re:That's silly.

[Anonymous Coward]

...or maybe you're just being a jerk.

Re:That's silly.

[chis101]

When I said "Is it really?" I was genuinely asking a question, I wasn't trying to offend you. I am sorry if you took it that way.

A failed write wouldn't be seen by the OS as "it doesn't seem like anything went wrong", and thus the source would not be deleted. However, if nothing is reported wrong, I don't believe it is reasonable to expect the entire file to be validated without the user requesting it, especially over a slow network connection - the specific scenario I was referring to anyways.

Now, if the destination server supported sending a hash of the transfer, that would be a better solution then validating the entire file. But I still can't see a move really being "copy, read entire file back, delete source." What I was writing to a network share that I had write access to but no read access?

Re:That's silly.

[the_lesser_gatsby]

You didn't offend me. Sorry if I seemed a little brash, but I often come across developers who give me these sorts of problems. ('Make it right before you make it fast' is the message given here).

The point is, you've got to verify it somehow if you're going to delete it, when I said 'read it back' this means 'ensure it's the same as the source'. You may have a facility on the other side (depending on what sort of transfer this really is) to get a hash back, or you may even be happy with a size report (starts to get dodgy). For the 'write but no read' situation (is that WOM..?), I would still insist on some kind of verification otherwise I'd do a copy not a move.

Re:That's silly.

[Anonymous Coward]

Isn't this a Mac? I thought they were supposed to be easy to use.

Nah. Apple secretly (?) threw all pretenses to ease of use out the window the day they chose to base their future OS on a bastardized version of UNIX, the hardest-to-use operating system in the sad and depressing history of mankind.

Tiger has this problem as well!!!

[itsybitsy]

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.

Re:Tiger has this problem as well!!!

[Chouonsoku]

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.

Re:Tiger has this problem as well!!!

[dhavleak]

I would normally assume that Apple have test automation to cover such scenarios. I wonder if this was a one-off, or are more people reporting this issue?

Re:Tiger has this problem as well!!!

[Liquidrage]

Well, so far that's 3. Across to different OS versions even.

Hey, maybe we should start keeping count. You get the even numbers, I'll take care of the odds.

Re:Tiger has this problem as well!!!

[Kadin2048]

Scenarios that involve physical disturbance to the hardware are not easily testable by automated regression-test systems. I have no idea what Apple uses internally, but "bump the hard drive" is not an option I've seen in most products.

It's the sort of thing you expect to find in human-driven system testing, where you actually set somebody loose and tell them to try and find ways of breaking things.

It's exactly the sort of thing I'd expect to slip through if an organization was depending too heavily on automated test strategies and not giving enough time to more holistic ones.

Re:Tiger has this problem as well!!!

[Liquidrage]

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.

Re:Tiger has this problem as well!!!

[Otter]

I've had that also (on Jaguar, IIRC) when an external drive lost power. Lost both the data and the old backup, simultaneously.

Re:Tiger has this problem as well!!!

[wizardforce]

yep, your story sounds a lot like a friend of mine and his laptop. The genius reinstalled his OS without doing a backup and surprise!! all his files are gone. Always keep a back upo and never ever simply move a directory unless it is absolutely impossible to do otherwise. DVD back-ups are your friend.

Re:Tiger has this problem as well!!!

[Anonymous Coward]

I lost my entire work when my primary volume disapeared after power outage, was told that disk is unaccesible. What?? I then realized that all my videos from Asia and Africa filmed previous year were gone, and I mean GONE, nothing even a bit was recovered. After that horrible accident I placed my iMac on a pedestal in the yard and shot it by my Remington into pieces. Never, never I would even consider any Apple product again.

Re:Tiger has this problem as well!!!

[Anonymous Coward]

yep, your story sounds a lot like a friend of mine and his laptop. The genius reinstalled his OS without doing a backup and surprise!! all his files are gone.

What does that possibly have to do with his story?

Re:Tiger has this problem as well!!!

[Anonymous Coward]

that possibly it is not very smart to be without backups perhaps?

Re:Tiger has this problem as well!!!

[Anonymous Coward]

If you didn't have backups of the data then you should never be allowed to use a computer ever again. You'd best take that Remington and shoot yourself into pieces...

Re:Tiger has this problem as well!!!

[dal20402]

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.

Re:Tiger has this problem as well!!!

[virgil_disgr4ce]

It just occurred to me: could Apple be ignoring this and other really basic filesystem problems because they're spending all their time working on something like ZFS? I.e., "we're going to switch out of this anyway so whatever?" It's still *REALLY* shitty of them, but that seems like a plausible explanation..

Re:Tiger has this problem as well!!!

[itsybitsy]

The issue is that when the external usb hard drive got bumped it lost it's connection with the Mac Book Pro which then proceeded to abort the file move and DELETE the files. The problem are the brainless programmers at Apple who don't know about fault tolerant programming techniques - which are especially important in an actual operating system! This is both a hardware fault and a software fault.

It could have just been a hardware fault though if the Apple programmers know anything about fault tolerant programming which they obviously don't. (The frequency with which my mac book pro crashes with Leopard and Tiger is also an indication that they don't know what they are doing. Sheeh. Who would risk putting device drivers, file system servers, etc... into a micro kernel? Please upgrade to minux or exokernel, Apple!!! Thanks).

Note: the data was being copied from one usb drive to another when the lap top got bumped (not a big bump either).

Re:Tiger has this problem as well!!!

[Anonymous Coward]

that's what you get for stealing, er, backing up music

Re:Tiger has this problem as well!!!

[Hal_Porter]

If Apple had called it Tigger this sort of thing would have been more understandable. Macho code names are a bad idea.

Re:Tiger has this problem as well!!!

[DurendalMac]

And why the hell were you not using a standard copy operation instead of one that deletes the source when the (supposedly) copy is done? Very, very rarely do I ever use option-drag or an mv in the Terminal to copy files. I always do a standard copy, verify the destination, THEN delete the originals if need be.

Re:Tiger has this problem as well!!!

[Liquidrage]

The USB part doesn't matter.

There are millions of reasons it could fail to copy. If it's broken up as one could safely assume, the "why" it failed isn't where this needs to get handled. There's going to be several layers of abstraction involved here. As is even pointed out in TFA, all that needs to happen is if it doesn't finish writing without error, don't remove the original files.

Re:Tiger has this problem as well!!!

[Anonymous Coward]

Were this Windows, I'd assume you then recovered the lost files in a few minutes with an easy free tool. Do such tools not exist for Macs?

Re:Tiger has this problem as well!!!

[dvNull]

So what you are saying is that even stuff like moving files should not be done without backing up at every possible opportunity.I am glad trivial tasks don't cause data loss on my other machines.

Re:Tiger has this problem as well!!!

[bigdavesmith]

I can totally relate. I'd been doing pretty well working as a consultant for the last 10 years, and I'd saved up a lot of money under my mattress, then one day, my house burned down, and all the money was gone, and I mean GONE, nothing even a bit was there. After that horrible accident I walked into the woods, and just sawed down every tree I could find, and squirrels too. Never, never I would even consider a house made of wood again.

But seriously. That does suck about the videos. Even though you should have backed them up, and not just blame Apple, I feel your pain.

Re:Tiger has this problem as well!!!

[TheLink]

AFAIK this is not a file system level problem. It is "above" that level.

So if they don't fix this problem it is likely to still be present even if they switch to ZFS.

Re:Tiger has this problem as well!!!

[IceCreamGuy]

Dude, Mac users are just getting this kind of functionality? Come on, we've had that feature in Windows for years...

Re:Tiger has this problem as well!!!

[tftp]

I presume as you bumped the notebook the accelerometer decided to park the drive to protect it, and this caused it to become offline. This is a very usual situation with portable equipment, and losing data is indeed unwelcome.

Re:Tiger has this problem as well!!!

[tftp]

As other people mentioned, if a modern luxury computer offers "Move" then it better do it, and do it right.

But to answer your question directly, copy-verify-delete is a dangerous thing in itself. You have hundreds of files to move, and you carefully selected what you want. Now you can do cut and paste (or move) and finish the task right here. Or you can drag the files as a copy... and what then? How do you run a quick cmp or diff on two selections? You need to be very familiar with tools (not standard ones either) to do this. While doing all that you need to keep your selections, or else you will delete not what you copied. And all this manual labor is needed only to avoid a bug in the OS which has sole purpose in life to copy and move your files around!

A properly functioning move is therefore preferable to the manual sequence if move is what you ultimately want.

Re:Tiger has this problem as well!!!

[tftp]

I can understand him. He seems to be an artist (filmmaker) and not a computer scientist. He bought a Mac because it was advertised as "it just works". There was no user-friendly backup mechanism before Time Machine, as I understand, and large external USB or Firewire drives were rare (I have two 570 GB drives today.) Total loss of data is something that geeks know about, but your typical artist wouldn't even think about as a possibility! Ok, he failed to back up, however his computer failed him by making the data irrecoverable.

Re:Tiger has this problem as well!!!

[Anonymous Coward]

Scenarios that involve physical disturbance to the hardware are not easily testable by automated regression-test systems. I have no idea what Apple uses internally, but "bump the hard drive" is not an option I've seen in most products.

You're not a programmer, I take it.

Sun has far more extensive failure-mode tests than this for ZFS.

I'm not even a systems programmer -- I'm a web programmer right now -- and I write tests for weird crazy failures every day. If it's not tested, then it quite probably has a bug. We have things like mocks, fakes, and stubs, which make it really easy to simulate hardware failure in software tests.

If you can't (or don't) write a test for hardware failures, you have no business being a systems programmer.

Re:Tiger has this problem as well!!!

[dal20402]

Maybe I'm just too geeky, but I find your argument smacks of willful ignorance -- kind of like saying "The salesman didn't tell me I had to change the car's oil when I bought it."

External hard drives (or DVD-Rs, if a backup of a small amount is all that's required) are available right next to that iMac in the Apple Store, at prices that are only a little bit outrageous. SuperDuper has been a very, very easy-to-use backup program for years, and is widely publicized in even the most beginner-level Mac magazines and online materials. (Or, for a one-time backup of something like travel movies, a Finder copy works fine.)

People have been advised to back up their data by ads, non-techie magazines and even the newspaper at least since I've been old enough to read. (I'm 31.)

To me, it just seems like common sense that machines, no matter how user-friendly, break sometimes. If something is that important to me, I'm not trusting it to just one mechanical device.

Re:Tiger has this problem as well!!!

[background image]

The moral of this story: always, always make backup copies of your money.

Re:Tiger has this problem as well!!!

[Anonymous Coward]

So the move function failing is his fault?

Way to attack the messenger.

Re:Tiger has this problem as well!!!

[dal20402]

He said nothing about the buggy move function causing his data loss, or about any other cause. (It seems he's too technologically clueless to figure one out, anyway. I don't know how he got onto Slashdot, unless he's a troll.)

And OSes have bugs. That doesn't excuse Apple, but anyone who doesn't have a backup at this point in computing history is both willfully ignorant and bereft of common sense. I simply don't have any sympathy for their data loss, no matter what the cause.

Re:Tiger has this problem as well!!!

[dal20402]

Posted too soon. My last paragraph is a little too broad. It should read "...but anyone who doesn't have a backup of year-old data at this point..."

Re:Tiger has this problem as well!!!

[Anonymous Coward]

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

That's probably what he was doing when the system destroyed it.

Re:Tiger has this problem as well!!!

[Kadin2048]

Those test suites are nice, but none of them actually cause a hardware failure or disconnect. If that's what causes the data-loss issue (and it seems that there are other ways that you could cause/simulate it in this case, because it's happening on a higher level of abstraction than the bare metal), then you'd need to do some actual testing where you actually messed around with the hardware in order to determine the interaction.

I'm not arguing against automated testing; automated testing is great. But I'm saying that you also need to do simulated real-world testing, with the actual hardware, and let people try to break it. If you're only testing using software tools you're always going to have a blind spot at the very bottom levels.

Re:Tiger has this problem as well!!!

[kehren77]

I don't mean to pick on you, but since you actually used the words "backing up", I feel I need to point something out. By default when you drag anything from one disk to another it doesn't move the data, it copies it. So you would have had to specifically told it to move the files instead of copying.

Now I only point this out because you said you were "backing up" your music. You specifically told the system to MOVE your music. MOVE does not equal backup. COPY does.

I know that it's an issue of semantics.

Now here's my question. Who does this? Do a lot of people move files from disk to disk instead of copying them? And why? Does it really save you that much time? Doesn't it make more sense to copy the files and then deleted them from the source if you don't want them anymore? That way you can verify the copy before deleting the originals.

Re:Tiger has this problem as well!!!

[tftp]

I find your argument smacks of willful ignorance

Yes, it does - I put myself into this filmmaker's shoes. He may be not reading the computer magazines or web sites that geeks read. He might have seen DVDs and thought "I need a few when I start sending my movie for review." He might have seen SuperDuper somewhere and thought it is a CD duplication software (that's what the name suggests.) I can come up with a bunch of excuses on his behalf, and in fact many of them would be reasonable for a non-geek type.

But do you know what Quicken does? It prompts you to do backups, and guides you all the way. You have to actually go out of your way, intentionally decline a default choice, to skip the backups. Quicken offers backups over the Internet (to Quicken's own servers), then to a removable media, and then to any other location. Backups default to once per 3 days (I think) and they are time-tagged, and it is trivial to restore a database from any backup (one click, and it does not destroy your current data either.) This is the smart way to do it. Why a consumer-oriented computer can't do the same?

Re:Tiger has this problem as well!!!

[Anonymous Coward]

Nah... that's why they developed Time Machine

Re:Tiger has this problem as well!!!

[Just Some Guy]

Total loss of data is something that geeks know about, but your typical artist wouldn't even think about as a possibility!

Don't artists have house fires and burglaries and lightning strikes, too? There are many reasons to backup besides hardware failure.

Re:Tiger has this problem as well!!!

[Chouonsoku]

Your correct in that I was moving files, so, in a sense, I wasn't backing the files up. But, your statement on what makes more sense than the other is irrelevant seeing as that most recent operating systems run a checksum on any file that is moved or copy on it's own. So, the integrity of the files is verified automatically. An example of this would be if you copy or move a file from a hard drive in Windows and receive the "Cyclic Redundancy Check failed" error. Anyway, the reason I said backing up rather than moving was because, while I was deleting the files from the source, I would leave the files on the external hard drive after copying them back to my Mac after the Leopard installation had completed. So no matter how you slice it, I was backing up the files. Just not in the same manner of speaking as you may back up yours.

Re:Tiger has this problem as well!!!

[kehren77]

Yes it's true that most operating systems have some sort of verification process built into their copy/move process. Maybe I'm just paranoid, but I'd rather take a little bit of extra time to do the copy and then delete the originals rather than letting the system automatically do the delete for me. I'm not saying I go through and open every file after the copy, but I usually try to make sure that all of them copied.

Perhaps this is no longer the case, but it was my understanding that the Move procedure in OS X essentially did some form of a 'mv original/file_name destination/file_name' and once it finished it did 'rm original/file_name'. Whereas the Copy procedure just did the mv command.

And again, it's a semantic debate as to whether or not you were backing up your files. My assertion is that until you are actually creating a second set of files, you are not backing them up. The scenario that you described where you were simply moving files, doesn't result in 2 copies of the file and is therefore not a backup.

In either case, it sucks that you lost files. I really do hope that you were able to recover them or at least able to recreate them from some source (CD, iPod, etc...). And hopefully Apple will fix the problem.

Re:Tiger has this problem as well!!!

[Anonymous Coward]

No need, Macs just work.

Re:Tiger has this problem as well!!!

[tepples]

Scenarios that involve physical disturbance to the hardware are not easily testable by automated regression-test systems. I have no idea what Apple uses internally, but "bump the hard drive" is not an option I've seen in most products. But products could simulate a physical failure to an extent. For example, now that the world has documented this failure mode, it might become standard procedure when testing a file manager to set up some sort of mechanism that interrupts a storage device's power or data, even if it's as simple as a relay controlled by some USB I/O box.

Re:Tiger has this problem as well!!!

[tftp]

And how many of us, geeks, have serial numbers of all home electronics recorded, and all other valuables photographed, and certified by a notary public for insurance purposes in case of such house fire or burglary? This is highly recommended, and you can read about it in many boring insurance brochures. Do we read them, though? I think only insurance people, seeing clients' disasters every day, really understand why this is important, and why house alarms are a good idea too. The rest of the people just presume that such bad things will never happen to them. And if I do not have a serial number of my PS3 recorded and stored in a bank, then I have no right to blame an artist for an omission in his handling of his computer.

Re:Tiger has this problem as well!!!

[Dephex Twin]

Yes, it does - I put myself into this filmmaker's shoes. He may be not reading the computer magazines or web sites that geeks read.

The guy in question here posted his anecdote on /. for god's sake! News for nerds!

Wierd

[darkcmd]

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.

Re:Wierd

[Anonymous Coward]

It isn't just samba, it is any "move" done in the finder. If the destination disappears during the copy phase, "poof" all data gone.

Re:Wierd

[cnettel]

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:Wierd

[Anonymous Coward]

It isn't just samba, it is any "move" done in the finder. If the destination disappears during the copy phase, "poof" all data gone.

This is bad. On the other hand, I don't think I've ever done a Move in my life. If it's going to another device I copy it, then delete it myself.
Obviously there are situations where a move is much preferred, but I think most people would never encounter this bug.

Re:Wierd

[gutnor]

Rollback moderation ... tried to go for funny but offtopic was the fastest

Re:Wierd

[NMThor]

This is bad. On the other hand, I don't think I've ever done a Move in my life. If it's going to another device I copy it, then delete it myself.
Obviously there are situations where a move is much preferred, but I think most people would never encounter this bug. I agree. But then again, we aren't "most people." Thankfully, IIRC (I know it's true in Windows) the default operation between volumes is always a copy (via "click and drag"), and you are forced to specifically request a move (cut-paste or holding down a modifier key). However, a lot of people I know use the "cut-paste" option so I could see this problem coming up a lot (if, of course, more people at work used Macs :)

Re:Wierd

[Anonymous Coward]

The first time I saw someone move a file in Windows via cut and paste I couldn't believe it. "You're putting an awful lot of faith in that working right," I thought, even though I was pretty sure that if something went wrong the file would magically reappear where it had been. Just the idea of that file being in "limbo" for that time gave me the creeps.

Re:Wierd

[jibjibjib]

In Windows, when you "cut" a file it just makes the file hidden. It doesn't actually delete the file until it's been "pasted" somewhere else.

defectivebydesign

[Anonymous Coward]

This is part of the file copy sandboxing that prompts "Do you wish to currupt data on loss of destination media? Cancel or Allow?"

Dumb users just don't know how to answer. This is a PEBKAC problem as OS X is infallible.

Re:defectivebydesign

[klubar]

You have to word the dialog box more precisely. "Do you wish to not allow data corruption or success on loss of destination meda?" Cancel? Retry? Abort? Ok?

A great disturbance in the Apple

[syylk]

...As if millions of fanboys suddenly cried out in terror and were suddenly silenced.

Re:A great disturbance in the Apple

[kerohazel]

Yes, but if their data is stricken down, it will become more powerful than we can possibly imagine.

Re:A great disturbance in the Apple

[zgregoryg]

This is going to be a Big Problem for all the artsy stoners. The former problem was Dang, where'd I just drag the directory too?

Re:A great disturbance in the Apple

[ILuvRamen]

In memory of them, I'm officially nicknaming Leopard: Vistapard.

Re:A great disturbance in the Apple

[Anonymous Coward]

that is why I read /. Well done, sir. Well done.

Re:A great disturbance in the Apple

[Peter La Casse]

In memory of them, I'm officially nicknaming Leopard: Vistapard.

"Vistard"

Re:A great disturbance in the Apple

[wildsurf]

In memory of them, I'm officially nicknaming Leopard: Vistapard.

Leoptard.

Re:A great disturbance in the Apple

[rubycodez]

"Move the file, or move not. There is no try."

"The filesystem is not as forgiving as I am."

Re:A great disturbance in the Apple

[larpon]

Mustard? Damn I so got that one wrong... :(

Re:A great disturbance in the Apple

[UncleTogie]

This is going to be a Big Problem for all the artsy stoners.

Correction: This'll be a problem for the Yuppie stoners. The rest of the stoner crowd moved to other OSs long ago.

This problem, as much as I like to jeer at elitists, is not Mac-only... We just read how Vista freaks around the 16,384 file number when copying. I could rant about "flaws" like this in each of the "big three", Linux, OSX, and Windows. But I'm not. Why?

They're going to happen.

Folks, ya have to remember... At present, and especially commercially, "quality assurance" means jack when you have a set-in-stone release date. Whether it's vaporware like WinFS, or trying to sneak in some code before a freeze, rushing due to financial/time concerns are what's screwing product quality far more than who's making it.

Re:A great disturbance in the Apple

[Anonymous Coward]

"Don't destroy the Leopard Fanboys' data - they are a harmless people."

"Proceed with the demonstration; we'll deal with those ipod friends of yours soon enough."

N.B. It's worse than we thought - I just tried bringing up a context menu by right-clicking, but nothing happened!

Re:A great disturbance in the Apple

[ILuvRamen]

okay to you and other guy...I already call Vista Vistard so we can't have that. And Leoptard doesn't have Vista in it. So since Leopard if the Vista of macs and you can't settle on Vistapard then...*thinks way too hard to take this joke way too far during the Scrubs commercial break because he just hates Apple that much*
The Vistapple iLeoptard MacOSux
BOOYAH! rofl

Re:A great disturbance in the Apple

[riddlermarc]

All the Mac fanboys in the office will shut the hell up.. "what, Apple aren't perfect?".. oh dear, where's my data on my Linux (aka FREE) system - oh hang on, there it is.

Re:A great disturbance in the Apple

[ne0n]

"Move the file, or move not. There is no file."

"Do not try to bend the file; that's impossible. Instead only try to realize the truth: There is no file."

Re:A great disturbance in the Apple

[e4g4]

How about just "Leotard" :P

Re:A great disturbance in the Apple

[zgregoryg]

>> Correction: This'll be a problem for the Yuppie stoners. The rest of the stoner crowd moved to other OSs long ago. Good point!

Re:A great disturbance in the Apple

[Charcharodon]

No you mean when their data (iTunes library) is stuck down, their credit card bill will get bigger than they could possibly imagine.

Re:A great disturbance in the Apple

[splutty]

Or maybe just Leotard? It looks nice, but you really want it gone?

Terrible bug

[thegrassyknowl]

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

[Liquidrage]

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

[thegrassyknowl]

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

[El Lobo]

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.

Re:Terrible bug

[Dephex Twin]

You're right, as long as you have a good external backup drive system going. But it doesn't keep stuff safe without a place to do backups.

Re:Terrible bug

[Knara]

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

[SnoopJeDi]

Another thought springs to mind... is this even that critical?

This is definitely critical in the sense that something so simple and blatant slipped past the developers and any testing done.

I suppose it's not fatal in a sense if Time Machine provides a workaround, but obviously a workaround never precludes the existence of a bug.

Re:Terrible bug

[El Lobo]

No, understand it. It's not critical for Abble. If the problem was in Vista it would be .. OMFG, M$ are teh suxxx!

Re:Terrible bug

[LM741N]

Time machine? Yes, and all you need is a tardis.

Re:Terrible bug

[laffer1]

What if your time machine data is corrupted due to the bug?

I had the external drive used for time machine dive off the network because the port is very sensitive on my new seagate drive. A slight bump will do it. Sure it will recover eventually, but if something happened quickly after time machine would have synced, then poof.

It should be fixed as it's serious. Not every Mac users runs time machine. I'm the only person I know using it right now.

Re:Terrible bug

[nine-times]

It's true that having a good backup (in this case, Time Machine snapshots) does mitigate the problem of data loss, it doesn't remove the importance of the OS maintaining data integrity. Losing data during a move/copy simply should not happen.

Re:Terrible bug

[myowntrueself]

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?

Critical in comparison to what?

Making sure the iPhone shipped on time and that its first major upgrade would brick unlocked phones?

Sure, Saint Steve would *obviously* say that the iPhone deal was far more critical than mere data loss on a mere workstation...

Re:Terrible bug

[Anonymous Coward]

Yes the system will be restored with Time Machine.

Re:Terrible bug

[Anonymous Coward]

Yeah, I'm sure it'll get fixed real fast, I'll grab the patch off the CVS and... oh, wait, this isn't open source, is it? :p

Re:Terrible bug

[RobertM1968]

Actually, without more information than the complainer posted, we know NOTHING.

Consider this, Samba crashed on his FreeBSD machine... and? when? how?

If Samba (on his FreeBSD machine) crashed after accepting the data and reporting back to the machine running Leopard that the transfer was completed but BEFORE it flushed it from cache to disk, how is Leopard at fault?

If Samba (on his FreeBSD machine) reported that the files were successfully written before it crashed (and actually finished writing the files), how is it Leopard's fault?

It is actually highly unlikely that it is Leopard's fault or many more data loss scenarios would pop up, since Finder is initiating the data transfer, AND THEN, the file delete. For this to actually happen, Finder (and the underlying code) would have to "forget" to get back a status from the FS driver indicating success on copy - and then start deleting the originals anyway. This "bug" would surface under any number of scenarios unrelated to this guy's FreeBSD setup.

Is his FreeBSD share in question on an NTFS partition with a flakey NT driver (or some other file system driver that's flakey)? Some of them will (incorrectly) report files written when they are not - which would trigger Leopard to (correctly) delete the files. I've experienced this exact same problems with some early JFS builds which incorrectly report a file written, then never get to it before the system is restarted or crashes. I wouldnt blame that on the OS of the connecting machine... it did what it was supposed to.

The only possibility that could make it a MacOSX problem is if the Samba share was reporting back something (else) that MacOSX thought meant "all done" thus starting the deletion of the original. And even in that case, it could be because of a non-standard Samba implementation on the FreeBSD box that is sending back an erroneous code.

You have to remember, Finder doesnt actually CHECK each file... it checks the return codes from the FILE SYSTEM (whether local or network) and then handles its next steps based off that (ie: success, disk full, write error, etc). This is the same procedure for virtually every operating system that runs on PC (yes, there are certain file transfer methods that actually do a file verification stage, but that is NOT the default for 99% of standard, end-user file transfers).

Even in the case of using a transfer method that actually verifies the files, it can be a moot point. If the files are still in cache, or the file-system structures are cached and those caches arent flushed and then the system or protocol/FS crashes, I'll lose data... but in the meantime, if the sending system requests "verification" of each file, the receiving system, via reading what is cached, will report that the writes were successful.

I fail to see how he - or anyone else - speculates this is a Leopard bug without more information. Yeah, it might be... but it more likely isnt.

Re:Terrible bug

[unamiccia]

iMindful is a bargain application (just $19.95) that automates copying data you move it. Just one of those wonderful little apps that keeps Mac users coming back. I cannot recommend it more highly.

Re:Terrible bug

[Hal_Porter]

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?

It reminds me of this -

http://www.blazed-up.com/he-hits-me-cuz-he-loves-me/

Re:Terrible bug

[Reaperducer]

Your post is full of facts and information supportive of Apple.

Prepare to be modded into oblivion by vengeful Microserfs.

Re:Terrible bug

[TheNetAvenger]

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.

Re:Terrible bug

[tknd]

I think the suggestion is removing the move command (there's a joke somewhere in there) and forcing people to use time machine. You know, it's like those pesky extra buttons on mice and all... we don't need those silly extra features.

Re:Terrible bug

[Hierarch]

Did you miss the part where Leopard reported an error on the copy? (No, really... I'm not being snarky, did you actually miss that screenshot?) Leopard correctly recognized that the transfer had failed, and still deleted the source.

To me, that's a pretty clear bug. What stuns me is that Apple isn't using the underlying "mv" command - since it should certainly deal with this situation. They rolled their own defective version.

Never re-invent the wheel. You'll have a square wheel with 13 lug nuts of all different sizes. Just go to Goodyear and take the tried-and-true.

Re:Terrible bug

[imuffin]

Leopard does have Time Machine. I tried setting it up today and was less than impressed.

When Apple was touting Time Machine before the release of OSX, Steve would talk about how you could sync to a firewire drive, a network drive, and even an external drive attached to an Airport base station. He had some quote talking about how the drive attached to your Airport base station can manage the backups for all the Macs in your home.

They took that feature out in the release version. So now to use Time Machine you have to physically connect a second drive (internal or firewire/USB) to the computer. That sure is a lot less useful than an automatic scheduled backup that works wirelessly.

Re:Terrible bug

[LeafOnTheWind]

Ugh, there are other big problems with Leopard though. For example, you know Time Machine? THE reason to buy Leopard? Doesn't work on SMB shares. Correct me if I'm wrong, but I'm pretty sure it worked in the betas. In fact, even if you use a linux AFP share, it won't run - Time Machine only works on wired external drives or other Leopard computers. Personally, I'm not going to buy a stupid wired external hard drive when I've got a perfectly good 2 TB SMB share on a Linux server. The fact that Apple just screwed everyone over like that shows exactly why I'm really disappointed in them this time around. Leopard broke so many things and put in so few good things, now I'm thinking it might have been a mistake to upgrade so soon (I really miss Afloat and Connect360).

Re:Terrible bug

[Anonymous Coward]

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

No, it doesn't. I have moved countless files in Tiger between drives and windows shares, and had quite a few deconnections. The behavior described in the article never occured (ie: the move ends with an error and the source directory disapear).

I DID however loose files during failed move operations, but was never able to pinpoint how it occured exactly. I can't even rule out human error (but I doubt it)

Re:Terrible bug

[Lars T.]

Yes, that's easily avoidable. If you know it exists. It's even easier to avoid if you don't know you can move files to another volume in the Finder.

Re:Terrible bug

[rice_burners_suck]

If Samba (on his FreeBSD machine) crashed after accepting the data and reporting back to the machine running Leopard that the transfer was completed but BEFORE it flushed it from cache to disk, how is Leopard at fault?

This reminds me of something I read on the Qmail developer's site. He said that when a mail server receives an email, it should write and flush to the disk (NOT do a lazy write) and only then should it report to the sender that the email has been received. He said that some developers disagree. He said that they're wrong.

Re:Terrible bug

[Anonymous Coward]

Actually, without more information than the complainer posted, we know NOTHING. Consider this, Finder failed on his MacOSX machine... and? when? how?

If Finder (on his MaxOSX machine) failed to check that the copy was completed BEFORE it deleted the file from the filesystem, how is Samba at fault?

If Samba (on his other machine) reported that the files were unsuccessfully written (and actually never finished writing the files), how is it Samba's fault?

It is actually highly unlikely that this is Samba's fault, or many more data loss scenarios would pop up, since Finder is initiating the data transfer, AND THEN, the file delete. For this to actually happen, Finder (and the underlying code) would have to "forget" to get back a status from the FS driver indicating success on copy - and then start deleting the originals anyway. This "bug" would surface under any number of scenarios unrelated to this guy's FreeBSD setup.

The only possibility that could make it a MacOSX problem is if the Samba share was reporting back something (else) that MacOSX thought meant "all done" thus starting the deletion of the original. And even in that case, it could be because of a non-standard Samba implementation on the MacOSX box that is misinterpreting an erroneous code.

You have to remember, Finder doesnt actually CHECK each file... it checks the return codes from the FILE SYSTEM (whether local or network) and then handles its next steps based off that (ie: success, disk full, write error, etc). This is the same procedure for virtually every operating system that runs on PC (yes, there are certain file transfer methods that actually do a file verification stage, but that is NOT the default for 99% of standard, end-user file transfers).

Even in the case of using a transfer method that actually verifies the files, it can be a moot point. If the files are still in cache, or the file-system structures are cached and those caches arent flushed and then the system or protocol/FS crashes, I'll lose data... but in the meantime, if the sending system requests "verification" of each file, the receiving system, via reading what is cached, will report that the writes were successful if it continues to misinterpret the return codes.

I fail to see how he - or anyone else - speculates this is a Samba bug without more information. Yeah, it might be... but it more likely isn't.

Re:Terrible bug

[Anonymous Coward]

Yes, and stop calling me Shirley.

Re:Terrible bug

[RobertM1968]

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:Terrible bug

[RobertM1968]

It depends on what tradeoff is worth less to you (and on how stable your machine(s) are). Do you want speed (cached) or less chance of data loss (flush each file from cache). I guess POV decides who is "right" - I set my caches to about 1GB with high lazywrite settings... I archive pretty regularly, and the changes to stuff on disk are minimal enough it doesnt matter. I might lose part of a log file... oh well. :-)

Re:Terrible bug

[RobertM1968]

Because, if you search (try Google... if you enter the right keywords you'll find the right info), there have been numerous issues of weird results and return codes if SAMBA is shut down with a session active.

Yeah, it could be an Apple issue as well... if it is, then I am sure there will be a patch announcement, and patch, in less time than for instance... the TCPIP throttling "issue" with Vista. No, not trying to be an Apple fanboy (I dont even own one)... but its just historical (how long the two take to fix something, and which one ignores the issues and pretends they dont exist until they take enough heat for them).

Either way, some more information would have been nice...

Re:Terrible bug

[Hierarch]

I confess that I find it hard to believe that Apple would choose an error message ("Sorry, the operation could not be completed...") when Leopard thinks the operation ("Copy," according to the title bar) actually completed. You may be correct, I don't know Apple's error codes. However, if that error code, 51, actually means some kind of clean-up failed, then I'd consider the error message itself to be a defect. It's seriously misleading.

You're correct that we would need to examine the exact SMB state between the two machines to know which side is buggy, but I just can't buy into the situation you're describing. Occam's Razor, and all that.

Since I don't have a Mac handy, I can't run the experiment you're implicitly suggesting. Anybody else?

Re:Terrible bug

[acvh]

the folks at Macintouch confirmed this isn't just an SMB problem. They replicated the problem using firewire drives.

I learned long ago that using a move is a bad idea. I think it was with DOS. Never did it again.

Coming from a lifetime of DOS and Windows to the Mac, I never use those modifier keys when clicking and dragging, so I didn't even know you could do a move this way. Lucky me.

Re:Terrible bug

[acvh]

I don't like it either. My biggest beef is in how TM decides it needs to update files. Changing permissions is enough for TM to think it needs to recopy data. We have a shared iTunes library that we have to change permissions on every time we run iTunes so that we can share playlists and add songs, TM wants to backup 90GB of songs everytime it runs. Yes, I have now removed that folder from TM's backups, but it seems to me like a shotgun approach to a simple problem.

Re:Terrible bug

[Score Whore]

They took that feature out in the release version.

Well, yeah. Bad things happen with your networked drive goes away.

Re:Terrible bug

[coolGuyZak]

At the same time, programming defensively would suggest taking the more conservative approach. I.E. If the result of a destructive operation is not known, abort the operation.

The least Apple could do is disallow moves between volumes--don't allow the circumstance to occur, if you can't prevent it any other way.

Re:Terrible bug

[RobertM1968]

Well, I'm NOT suggesting it's the answer... I'm suggesting it's a POSSIBILITY... ;-)

There is enough documentation online about weird results (or return codes or worse) if you shut down (various versions of) SAMBA (especially for Windows SAMBA shares) with active shares open... this could be one of them - or not... but without knowing more about the setup(s), who knows?

I wish I could confirm it (either way)... I do have a friend who has an Apple (well, multiple)... I'll ask him if he can try it out and see what is going on "behind the scenes" - when I next talk to him. He's both a PC and Apple tech, so he is computer saavy enough to dig behind the scenes to see whats going on at the SAMBA side...

Re:Terrible bug

[noidentity]

You have to remember, Finder doesnt actually CHECK each file... it checks the return codes from the FILE SYSTEM (whether local or network) and then handles its next steps based off that (ie: success, disk full, write error, etc).

And anyway, when the file was originally created, the program that wrote it most likely didn't try re-reading it to be sure the data was really written. So verifying after copying is somewhat pointless. I say somewhat because it is different in that you might be copying 1000 files, and if there is some undetected problem when writing then you lose 1000 files, whereas an undetected problem normally might cause you to lose the 10 files you wrote that day during normal saving, before you noticed the problem.

Re:Terrible bug

[syousef]

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?

It's called being a zealot. Every OS and in fact every significant piece of off the shelf software has them. These are people who would argue that it's not the software's fault even if it were proven that the software was designed and program to hunt down and brutally murder their family. If you complained that you bought the software and it had succeeded in killing your family they'd ask stupid questions like "Did you read the packaging? It says it will do that you know! You stupid user!" or "Did you remember to run with the -dontkillmyfamilyswitch ?" or tell you "You can work around that by downloading the hack that causes it not to kill your family".

Re:Terrible bug

[heinousjay]

Yeah, seriously. How could a bug that could destroy data be critical?

Re:Terrible bug

[Daengbo]

Can we stop the "Abble" troll already? I'm sick of it after only five minutes. Find a better joke.

Re:Terrible bug

[VGPowerlord]

It's a good thing there's not a Leopard server.

Oh, wait...

Re:Terrible bug

[Burning Plastic]

What would give a clearer picture would be to either pause the virtual machine running Windows, or preferably use a physical Windows machine and pull the network cable during the transfer - that would halt the transfer cleanly rather than clicking a turn off share option which as pointed out, might result in an unwanted completion code being returned to the originating mac.

Re:Terrible bug

[Anonymous Coward]

The only way to move between volumes (or even partitions) is to hold down a special key command while doing a normal copy. Unlike Windows, you cannot access the cut command for a file from a menu.

Re:Terrible bug

[RobertM1968]

Excellent suggestion - I hope he tries it and posts the results... that would narrow down what needs to be fixed - and where it is.

Re:Terrible bug

[Tim Browse]

Another thought springs to mind... is this even that critical?

Well, not compared to adding t0t4lly rad skinz to the Terminal program, no.

Re:Terrible bug

[Anonymous Coward]

His only other joke is "Linuzzz". Not much better.

Re:Terrible bug

[Pliep]

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

Re:Terrible bug

[Onan]

Actually, you don't need to go out of your way to do it safely; that's already the default. Dragging an item from one place to another on the same volume moves it, and between volumes copies it. That's been the Finder's behaviour since the 80s.

In fact, despite having used macs for fifteen years now, I didn't even know there was an option to non-copy-move between volumes. Which is why no one has complained about this before: it's an incredibly rare and hard to trigger bug. You need to be using a slightly hidden and non-default variety of file manipulation to do one particular thing at the same time as a volume completely disappears.

Don't get me wrong, it's absolutely a bug, and one that should be fixed. But it's an incredibly obscure one, which most of the doomsaying here is eliding.

Re:Terrible bug

[Anonymous Coward]

http://tomkarpik.com/articles/massive-data-loss-bug-in-leopard/
There ya go..

Re:Terrible bug

[TheNetAvenger]

Actually, Time Machine runs every two minutes.

You sure on the 2 minute thing? My Techs said it runs about once an hour when demoing it.

Another problem with Time Machine is when you are editing large photos or Video files. Imagine a 4GB Video file being backed up every hour, the backup drive fills rather fast, and then it starts to compromise other data if you have several large files being backed up every hour.

One of our Video editors has already turned off Time Machine and threatened our techs with death if they turn it back on.

Fanbois don't seem to realize that even with Firewire (or USB) shoving GBs of data to an external drive once an hour DOES slow down the OS, even when running at a low priority.

Notice that OS X doesn't allow you to use Time Machine on network shares for backups like Vista does. Time machine would saturate networks and bring most business networks to a crawl during the hourly backup.

I'll have to check on the 2 minute thing later today, I was pretty sure it ran hourly. I can't imagine it trying to backup every 2 minutes, as it wouldn't have time to complete one backup before another one was due, even with minimal file changes.

Re:Terrible bug

[Anonymous Coward]

You're missing the point. If the copy fails halfway through a folder move, then the *whole* source folder is deleted, including files that OSX hasn't even started to copy. There is no way the SMB server can be resposible for this.

An SMB problem could, potentially, lead to the loss of the single file being copied at the time of the failure. However, this is not the case here. When the server is killed, OSX is in the middle of copying a very large file. OSX knows the file transfer isn't complete because it hasn't sent all the data yet.

This is very plainly a bug in OSX.

Re:Terrible bug

[Anonymous Coward]

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.
--
A happy Windows user and developer, And PROUD of it!

(emphasis mine)

You go...er...dog. Keep up the fine work.

Re:Terrible bug

[Anonymous Coward]

The use of the work "fanbois" automatically makes you a troll.

Pity, as the rest of your post was interesting; you didn't need to degrade its content...

Re:Terrible bug

[Anonymous Coward]

One word: Apple.

Everything bad Apple does is automatically less bad than when someone else does it.

It's the same with Microsoft, but backwards- everything they do is automatically worse.

(in before "convicted monopolist")

Re:Terrible bug

[sgarringer]

Maybe this video editor should look themselves in the mirror. Installing a brand new version of an OS this early in the game on anything that helps bring money or business in the door is assanine at best and insane at worst. We won't be upgrading to 10.5 on any machines here until 10.5.1 and won't be piloting it with our users until 10.5.2. Rolling it out in-mass won't occur until at least 10.5.3 or 10.5.4 we're talking at least 18 months here...

This is a simple gotcha game.

[Anonymous Coward]

This is where everybody plays gotcha. It makes a lot of sense. Apple doesn't want the data and I support it. I don't want any user to lose data. This is a serious problem and data is important. That's why Apple has failed us. If a user is going to lose data, let's not argue over who's fault it is but begin to ask "What is this data really for?".

Wait...

[ackthpt]

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.

You just don't get it...

[juanfgs]

This is the new Leopard "iLostMyFrigginFiles" feature, next version they will add a badass black hole effect when it does that!

Re:You just don't get it...

[megaditto]

Black hole?

Come to think of it, that's probably how they power their TimeMachine.

Re:You just don't get it...

[DigiShaman]

Oh great! Soon, Windows users will experience "white holes" where Mac files magically appear in the My Documents folder.

Re:You just don't get it...

[nEoN nOoDlE]

wouldn't a hole where Mac files come out be named after Apple? Ie: The A-hole?

Re:You just don't get it...

[aliquis]

The question is what will happen to the progress bar/counter when you do that? What time will it measure? Is this why the files appear to be gone / not at the destination yet?

God help us

[artem69]

Software has bugs?? OMFG! This world is rolling straight to heck.

Par for the course?

[GoRK]

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.

Re:Par for the course?

[sigzero]

Yes...that one is annoying to me coming from the Windows world but I adapt to it.

Re:Par for the course?

[rbanzai]

I haven't noticed different behavior in any version of Windows. How do you merge similarly named folders during a copy/move in Windows? In my experience you get the same "Do you want to replace this?" type prompt you get in OS X.

Re:Par for the course?

[Blakey Rat]

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.

Re:Par for the course?

[JunoonX]

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.

Re:Par for the course?

[Anonymous Coward]

You get a prompt that says "Do you want to replace this. If the files are the same they will be overwritten, if not they will be merged." and that's what happens.

Re:Par for the course?

[nine-times]

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:Par for the course?

[Just Some Guy]

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

Pax isn't an OS X tool 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:Par for the course?

[Anonymous Coward]

Windows will ask if you are replacing files with the same name, but will otherwise merge them. Say you have two folders both called "stuff", one has files name "one, two, three" and the other has files names "four, five, six". If you drag the first one onto the second one in Windows, you get a folder with "one, two, thee, four, five, six" and on Max you get "one, two, three"; the other files get erased. Not set to the trash can; erased.

Re:Par for the course?

[bunco]

Windows will merge the files from the source directory to the (duplicate) destination directory overwriting any dups. It doesn't replace the entire directory contents. /alpha/baz/(one,two,three) /beta/baz/(one,four,five)

Let's say I copy directory /beta/baz to /alpha/

Windows: /alpha/baz/(one,two,three,four,five)

Some other OS: /alpha/baz/(one,four,five)

Basically, it nukes the conflicting /alpha/baz and then performs the copy. Brain dead behavior if you ask me.

I'm new to OSX so I'll have to test this later.

Re:Par for the course?

[GaryPatterson]

The dialogue box that appears says "An older item named "Documents" already exists in this location. Do you want to replace it with the newer one you are moving?" The options are "Stop" and "Replace."

There is no "OK" button, but leaving that aside, the message makes it pretty clear that this is a folder replacement happening, not a merge. That's not stupid design, but a different design choice. I find the merging concept you describe more confusing, but that's my personal preference.

The Mac has exhibited this same behaviour since 1984, so even if you dislike this design choice, it's been consistent and predictable across all OS versions and releases.

Re:Par for the course?

[k2enemy]

FYI, you can merge with either "ditto" or "rsync", both of which are included with the OS.

I have no idea what you are talking about when you say "Leopard's newfound support of hardlinks". OS X has always supported hard links, just not for directories. As far as I know, in Leopard there still isn't really support for hard linking directories. Time machine uses a logical equivalent, but I've read that it is not implemented with hard links per se. I haven't been able to find a way for users to create hard links to directories, but if you know, please respond.

Re:Par for the course?

[node 3]

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?

Re:Par for the course?

[CODiNE]

Maybe I'm weird but the way I'm used to doing it is to go into the Documents folder, select all... copy, go to the destination Documents folder and paste. It'll then throw up a warning for every conflicting file name asking if I want to overwrite or leave the original, it also has a check box for "Use this answer for all overs". Maybe it's just my command line background but it seems logical to me.

Isn't it standard UNIX to delete the target before moving a folder to an already used name? First it may complain about the destination already existing, then you can redo the command with a force option, isn't that essentially what you do in the OS X GUI when overwriting a folder?

Re:Par for the course?

[georgewad]

What happens if there's a nested dir? Does it also get merged with the nested dir on the receiving end?
If so, I guess windows gui copy is more like rsync, while mac copy is more like cp.

Re:Par for the course?

[mctk]

or a Linux environment ripped-off from Linux

Forking Linux developers!

Re:Par for the course?

[JunoonX]

I just tested it out, yes it works as expected; however, it prompted (continue,etc) for the 1st nested dir it encountered.

Re:Par for the course?

[Anonymous Coward]

'cp -r' didn't work for you? To get around OS X's directory copying problems I always just use cp -r from the command line. Shouldn't have to, but what can you do?

Re:Par for the course?

[ToasterMonkey]

I think you're right. I remember performing this operation on Windows 95 my first time, and I completely expected it to overwrite the old folder, so I made a copy just in case. I think some people just got used to how other file managers do it, and forgot what their initial expectations were. OS X more consistently models the idea of moving an object to a location where a same named object exists.

I've probably done a lot more delete+move procedures than I've needed to do merges now that I think of it. I do this with every JDeveloper upgrade anyway. Still, it would be very handy to have a "merge" option in finder.

Re:Par for the course?

[tuffy]

The standard UNIX behavior of "mv /tmp/foo/ /bar/foo/" is to make "/bar/foo/foo/" if "/bar/foo/" is already a directory. If "/bar/foo" is a non-directory file, mv(1) will refuse to remove it, even with --force.

Re:Par for the course?

[Anonymous Coward]

Windows merges folders just fine. When you drag a folder in Windows Explorer over a folder that has the same name, Windows will merge the two directory trees. It will also tell you that it is doing that and ask you to confirm that you want to merge. It is a massively useful feature when overlaying things like patched source trees one over another.

Re:Par for the course?

[complete loony]

But you don't lose the entire folder, you only lose the individual files being overwritten.

Re:Par for the course?

[nuzak]

> Isn't it standard UNIX to delete the target before moving a folder to an already used name?

Unix most certainly merges directories, and doesn't delete them.

The Mac behavior basically goes back to the original HFS, which technically didn't really have directories at all, just a UI that faked them. A folder was just a file with a list of files in it, so naturally the folder would be overwritten by such operations. Nowadays, the fact that MacOS still doesn't even give you the option to move the freaking conflict out of the way with an automatic rename, let alone the merge many people expect, strikes me as stubborn hanging on to an anachronistic misfeature, all in the name of removing the confusion of choice in the UI.

Re:Par for the course?

[Anonymous Coward]

Do rsync, GNU mv/cp/tar, or pax make sure that files are fully committed to disk (using fsync(), for example) before closing them?

If they don't, what happens in the scenario where the command finishes but the copied files' data is still in the system file cache when the destination disk or share goes away or fills up? Most of these programs can delete source files, so you could end up losing your data.

I like that the star version of "tar" does the safe thing by default (calling fsync() to catch any errors) but gives me the option of turning it off with the "-no-fsync" flag if I want speed.
"star" also has the ability to diff and merge directory trees.

Re:Par for the course?

[crabpeople]

Wow thats fucking retarded!

How can you screw up such a basic thing as merging two folders contents??

Re:Par for the course?

[TheNetAvenger]

I haven't noticed different behavior in any version of Windows. How do you merge similarly named folders during a copy/move in Windows? In my experience you get the same "Do you want to replace this?" type prompt you get in OS X.


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:Par for the course?

[TheNetAvenger]

Windows will ask if you are replacing files with the same name, but will otherwise merge them. Say you have two folders both called "stuff", one has files name "one, two, three" and the other has files names "four, five, six". If you drag the first one onto the second one in Windows, you get a folder with "one, two, thee, four, five, six" and on Max you get "one, two, three"; the other files get erased. Not set to the trash can; erased.


You act like you are talking about Windows95 and not Win2K, XP, and especially Vista.

Win2k forced users to go through 'every file' to confirm any overwrites, XP added a features so you could Shift click to tell it to overwrite all of them, and Vista has a very elaborate system of merging folders, you should check out a modern version of Windows, and especially Vista.

They simply do not work like this anymore, in fact for 10 years now unless you are doing something really wrong.

Win2K and XP power users would also use XCopy, Vista brings a lot of the validation and automation of the merging feature to Explorer, and I haven't needed to use XCopy in Vista.

Re:Par for the course?

[jay-be-em]

Wait, it actually did merge the sub-folders?

That seems like ridiculously inconsistent behavior.

Re:Par for the course?

[TheNetAvenger]

Basically, it nukes the conflicting /alpha/baz and then performs the copy. Brain dead behavior if you ask me.

Vista works very differently, not only Folders are confirmed but every file in the folders are confirmed with options to replace/don't copy/create second copy...

So ya this sucked in older versions of Windows, but Vista does a great job of handling this, better than any other GUI file manager I have ever seen to date.

Maybe you should try Vista instead of OSX... But again if MS was doing their job and was touting features like this in Vista, people would find more reasons why Vista has a lot of things to offer. Instead MS's marketing is retarded and nice features like this are NEVER mentioned and none of even the tech press notices them or points them out to users.

And trust me when I say there are literally 1000s of features like this that make the difference between Vista and XP night and day for daily usage.

Re:Par for the course?

[CorporalKlinger]

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. The typical user drags and drops a folder called "photos" from their flash drive to their desktop, which - unfortunately - also contains a folder called "photos"... they click the wrong button thinking it will replace duplicate files WITHIN the folder, not the folder itself (a careful wording change that could easily be missed in a hurry) and bam - all of the photos that were on the desktop to begin with are gone! For a user who seems reasonably knowledgable about Apples to say that the easiest way to do a simple directory merge is to whip out a command prompt and do some Unix-style command prompt kung-fu proves just how flawed Apple's little Finder thing is. It's time for a total rework.

Enough of the fanboys being wowed by cute translucent graphics and crap... improve the functionality first, for goodness sake. Oh... and when I'm closing a maximized window in Windows 95, 98, ME, NT, 2000, XP, or Vista, I can click in the top right corner of the screen (not actually on the "X" to close the window) - and it closes the window. On a Mac... if you can even figure out how to maximize, you gotta click right on. Don't click that piece of desktop showing in the middle of the CD icon on your screen on a Mac - you didn't click the icon PICTURE, so it won't click the icon. My mom with her arthritis has no problem with the PC - click in the vicinity of the icon and it knows what you're doing. How is even something as simple as scroll-bar manipulation, window manipulation, and icon manipulation STILL so flawed in Apple's OS? God-damnit, I want my file menu at the top of the window not at the top of the screen with that stupid little Apple icon. When I click "FILE" in an inactive window on a PC, it opens the menu without trouble. On a mac... click the window first to activate, wait for the menu at the top to change to that program's menu, then go click on file. Waste of time. Programming design flaws. Stop trying to hold onto the past... make something NEW and FUNCTIONAL for a change.

I used to recommend Macs because they were easy to use and relatively safe when manipulating files and data - so I told people I liked to get them. Now I recommend them to people I hate - I hope they lose their precious family photos because of a basic programming glitch... and blew $1800 on an overpriced piece of shit that some has-been in a turtleneck brainwashed them into thinking was the best thing in the world.

Re:Par for the course?

[TheNetAvenger]

PS, I should also mention...
This also doesn't take into account sync features in either XP or Vista.

(Which is a different topic, but is why in the Windows world, merging or copying froms to and from server shares is transparent once turned on and most users don't have to copy or merge folders in these situations. If the Mac OS X user that found this bug had a feature like offline files, they probably wouldn't have been moving data back and forth to the server by hand.)

If you are using external shares with either OS, using offline files handles the folder syncing automatically, so you don't have to do anything when you reconnect to your network, it just merges the files/folders automatically, ensuring no data is lost and is transparent to the user.

This is obviously used more on laptops, but even in corporate environments, where users could potentially be knocked offline from other workstations or servers. The data is still available, and when the network/servers come back online, all the users content is then updated to the server/workstations.

Vista also adds many new features in offline files, for example file comparisons, so only the changed parts of a file are transmited, it also is smarter about knowing what is new data, and merging files from multiple users on a share.

It also does several other things like encrypting the offline files, so if it is a laptop, the data pulled from the corporate server can't ever be retrieved if the laptop is stolen.

Kind of off subject, but handy and another set of about 50 features just in the changes in Vista Offline file technology that MS never touts or even mentions in the press.

Re:Par for the course?

[earthbound kid]

Simple solution: Change the dialog that pops up and says, "[Cancel] [Replace]" to one that says"[Cancel] [Replace] [Merge]". Done.

Re:Par for the course?

[Blakey Rat]

I meant to go for the more flamebait option and say "Linux environment ripped-off from Windows." With the typo it just makes no sense. Oh well.

Re:Par for the course?

[DaleGlass]

Why inconsistent? It can come useful.

For example, when working on source code, I have a source tree in SVN which doesn't include various external components, of which there are several. So I have a directory with all those components arranged in the structure they should be in inside the source tree.

When I check out a new copy of the source, I just overwrite it with the folder with the libraries, and this merges both trees. This way I don't need to go through manually putting every component in the right place.

It's the same as untarring or unzipping in Linux. Untarring over an existing directory doesn't remove its current contents. In fact that behavior is used to make primitive packaging systems for distributions.

Re:Par for the course?

[Anonymous Coward]

Open a folder, "Select All", drag into destination folder. ...then repeat for all nested folders whose name conflicts. If you are moving, say, a large directory tree for which you have multiple versions you are trying to keep in sync, might take a while.

Re:Par for the course?

[Score Whore]

Inconsistent by doing the same thing it did before?

Re:Par for the course?

[jay-be-em]

Yes, of course merging is useful. Here's what the post I replied to seemed to be saying:

Say we have / , /FOO and /BAZ/FOO as such: /FOO:
    README
    TODO
    src (directory)
    lib (directory) /BAZ/FOO:
    README
    src (directory)

From what I understand from this post and discussion (I don't have an OS X machine), using finder
to copy /BAZ/FOO to / will cause /FOO to be completely clobbered, leaving just README and the /BAZ/FOO version of src.

Now above a poster said this can be avoided by copying the contents of /BAZ/FOO, ie selecting all
in /BAZ/FOO and then copying into /FOO

A poster then asked my question, what about directories inside of /FOO (mainly src here)?

The reply was basically that 'i just checked and it works'.

I have a feeling the poster didn't understand what the questioner was getting at -- are these
subdirectories merged or clobbered?

In other words, if I do this select all then copy, do I get that /src directory merged or
clobbered?

If it gets merged, that's kind of weird, as just copying it directly there would clobber.

Re:Par for the course?

[stang]

[huge post touting Vista's folder move/copy improvements]

We get it. Vista's got some nice features for managing the process of tossing files around. You guys (you're obviously connected with MS) did a great job on that. Nice work on the parental controls, too.

Unfortunately, the actual tossing of the files is slower than crap. Low transfer speeds, random pauses, and a ludicrous amount of time needed to delete files.

And since it's 2007, can we think about getting rid of the ol' DOS drive letters? I mean that stupid media reader's showing six different letters, and they're all named Removable Disk [drive letter]. Between that, and the USB key I've got plugged in as a ReadyBoost device (there's another clever thing), plus external drives, DVD drive, disk partition, the Computer view in Explorer is a twisty maze of letters, all alike. Thanks though for getting HP to toss in a driver for my printer that only does the basics, because I really don't need yet another six drive letters. Hopefully there weren't any useful features left out.

Re:Par for the course?

[Anonymous Coward]

That is your second post in a row claiming features on Vista that do not work "just work". There is a reason the vast majority of users who have tried Vista find it lacking -- these so-called features you claim just work do not.

I cannot believe you just claimed copying files in Vista is something good about Microsoft's latest operating system. Copying files in Vista is the biggest fucking pain I have ever experienced since using cassette tapes to store Atari files.

I think you, TheNetAvenger (624455), are a paid Microsoft shill.

Re:Par for the course?

[spacebird]

Actually, on WinXP, what he describes is exactly what happens. You select the first folder and drag it onto the second one and you get this prompt. Selecting "Yes" merges the parent folder and prompts again for any nested folder, selecting "Yes to all" merges the parent folder and all nested folders. No prompts for individual files, and no shift-clicking involved. Are you sure he's the one who is using outdated info here?

Re:Par for the course?

[Basehart]

Yawn.

Re:Par for the course?

[Anonymous Coward]

"Forking Linux developers!"

developers,
  |-developers,
  |  |-developers,
  |  |  |-developers!
  |  |  |-developers!
  |  |-developers,
  |     |-developers!
  |     |-developers!
  |-developers,
     |-developers,
     |  |-developers!
     |  |-developers!
     |-developers,
        |-developers!
        |-developers!

Re:Par for the course?

[AJWM]

Let's say I copy directory /beta/baz to /alpha/

Windows: /alpha/baz/(one,two,three,four,five)

Just tried this on Linux; "mv" (or "cp") just complains and refuses to do anything with /beta/baz. KDE/Konqueror detects the conflict and asks if you want to cancel, rename baz, or overwrite baz. If you overwrite, you end up with what you show above for Windows, with "one" being the one from beta/baz, the old alpha/baz/one is toast (unless there was another link elsewhere to the same inode).

Re:Par for the course?

[VGPowerlord]

I think you're right. I remember performing this operation on Windows 95 my first time, and I completely expected it to overwrite the old folder, so I made a copy just in case. I think some people just got used to how other file managers do it, and forgot what their initial expectations were. OS X more consistently models the idea of moving an object to a location where a same named object exists.

I figure Microsoft just took the file cabinet route.

For instance, if I'm putting a Last Will and Testament into the Legal Documents cabinet, George W. Bush folder, I'm going to get rid of the old Last Will and Testament.

However, if I'm putting another George W. Bush folder into the Legal Document cabinet, I'm probably dealing with the same person and would take the documents out of one folder, put it in the other folder, and toss the empty one away (or save it for reuse later, file folders cost money).

Re:Par for the course?

[Anonymous Coward]

So instead of having 6 drive letters for the Removable Disk you'd rather it just say Removable Disk 6 times, and when you put in your SD card instead of remembering its X: you just guess which one it is?

Re:Par for the course?

[smcdow]

Under OSX? Sure there is. Say you want to merge the contents of two folders "a" and "b" into a new folder "c". It's pretty simple really. Start up a shell and run the following:

mkdir c && ( cd a/. && tar cf - . ) | ( cd c/. && tar xf - ) && ( cd b/. && tar cf - . ) | ( cd c/. && tar xf - )

et. voila!

Re:Par for the course?

[tftp]

This may be a traditional choice for a Mac, but it is a stupid choice. The OS should err on the side of caution and merge folders, not that it is difficult in any case. MS was right to not do rm -rf on a single, ambiguous button click. Protecting user's files is very important, or else (as someone did) your product might become a target on a rifle range.

Re:Par for the course?

[islarty]

Dude! I know this has nothing to do with the topic at hand, but I saw that you wrote this line on a forum somewhere on this site concerning Winamp's autohide feature: "A simple timer, with a user-defined delay, solves this problem. When the mouse moves to the appbar's edge, a timer is started. If, when the timer expires, the mouse is still on the edge, the appbar will show itself. If the user clicks on the top edge (indicating they want to see the appbar immediately), the appbar will show without waiting for the timer." I've been looking for something like this for ages! Do you happen to know a way to give Winamp's autohide feature a slight pause before activating? I'd appreciate any help! Thanks!

Re:Par for the course?

[Anonymous Coward]

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?

Because a folder is not a file?

Re:Par for the course?

[Echnin]

Damn. I couldn't figure out how I'd lost 200 photos when copying from my camera to a directory on my Mac a while back. Now I know.

Re:Par for the course?

[amliebsch]

And since it's 2007, can we think about getting rid of the ol' DOS drive letters?

They're not required, you know. Just remount the devices to an NTFS folder and delete the drive letter mapping. Your fingers broken or something?

Re:Par for the course?

[Anonymous Coward]

Yes. Perhaps. And unfortunately so do the bugs, hangs, crashes, and hundreds of thousands of vulnerabilities because the system at rock bottom is hopeless and beyond help. No amount of end user features will ever take away from that. Or do you want the world to continue to get inundated with spam and exploits because the file management API is better?

Re:Par for the course?

[willpall]

Open a folder, "Select All", drag into destination folder. And let all the subdirectories replace the other folder's subdirectories? Why should I have to manually recurse when my file browser should do this for me? OS X is the last OS that should require command line operations for a simple directory merge!

When merge is the default mode of operation, a replace is easy: I can simply delete the old folder and drag over the new one.

When replace is the default, there is no easy way to merge.

Treating folders just like files doesn't make sense here.

Don't get me wrong, I love my Mac. (Despite the uselessness of the Finder and of the [Home] and [End] keys.)

Re:Par for the course?

[Anonymous Coward]

it is because you are getting mixed answers, some saying what windows does and some what MAc does (or more to the point what is doesn't do)

simple Answer, Windows does it properly (yeah hard to admit but they do it right), they prompt the user if they want to merge/replace/make a second copy for both folders and files and give the option to automatically apply the same answer to all files in the copy process.

Apple. Completely F'ing drops the ball, you lose everything in the folder including other folders as it basically recreates it.

Re:Par for the course?

[Tim C]

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 a folder, so you can't take the analogy too far...

I'm a Windows and Unix guy, so to me merging folders makes perfect sense. I know I'm biased, but I'd have thought that a new user would think "hang on, if folders contain files, how come I can't just put all the files from the new folder into the old one like this? Why does it replace them all?" I know you could do it manually, but then you have to manually recurse through all the subdirectories. (And I appreciate you can use the command line, but that just raises another question - how come the GUI operates on a completely different principle?)

Re:Par for the course?

[Onan]

The Mac behavior basically goes back to the original HFS, which technically didn't really have directories at all, just a UI that faked them. A folder was just a file with a list of files in it...

Um. What exactly do you think a directory is on every other posix filesystem in the world?

(Hint: run "vi /" some time.)

Re:Par for the course?

[evalencia1]

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?

Because a folder is different from a file. When working with folders, you are actually using that to group files together. The folder itself is not the entity you're concerned with, it's the files inside it. If you move a folder onto another with the same name, you are actually telling the system "move the files in this location to this other location". I think this is the more frequent user scenario, rather than a user wanting to REPLACE the contents of one directory with another. I think in these cases, the one that loses the least number of files should prevail.

Re:Par for the course?

[Ox0065]

Now explain that to your Director who has strict filters that only accept binary (Yes or No) responses to IT questions... ...and gets Macs to NOT have these problems.

Re:Par for the course?

[TheNetAvenger]

I think you, TheNetAvenger (624455), are a paid Microsoft shill.


Sorry, just run a large company and deal with this stuff on a daily basis. When you are helping companies that in turn provide support to 1000s of companies, you tend to see a few things.

Prior to what I am doing now I was an OS engineer and taught OS theory for a few years in addition to a few years in UI research.

So when it comes to OS concepts, architecture, and usability, this is kind of my hobby.

Re:Par for the course?

[TheNetAvenger]

Yes. Perhaps. And unfortunately so do the bugs, hangs, crashes, and hundreds of thousands of vulnerabilities because the system at rock bottom is hopeless and beyond help. No amount of end user features will ever take away from that. Or do you want the world to continue to get inundated with spam and exploits because the file management API is better?

Go look up NT, the core of Windows. Then try to find someone that says NT is a bad design, especially for its time.

I won't argue Win32 is the best or most secure OS API set, but it is just a subsystem that sits on NT, and not NT.

I also won't argue that MS didn't fek up by not enforcing NT security in WinXP, but they learned their lesson. However, this doesn't discount the fact that NT has always had a very robust and intrinsic token based security model.

However I will stop people that think NT is a poorly written OS, or a bad design.

Re:Par for the course?

[Anonymous Coward]

Heh, filemanagers like Krusader for Linux have offered that for ages.
You can talk all you want, but there is nothing *new* in Vista. Nothing.

Re:Par for the course?

[SoupIsGoodFood_42]

Now I recommend them to people I hate - I hope they lose their precious family photos because of a basic programming glitch.

Buddha thinks you need to calm down a bit before your head explodes from a lack of compassion.

Re:Par for the course?

[nine-times]

The typical user drags and drops a folder called "photos" from their flash drive to their desktop, which - unfortunately - also contains a folder called "photos"... they click the wrong button thinking it will replace duplicate files WITHIN the folder, not the folder itself (a careful wording change that could easily be missed in a hurry) and bam - all of the photos that were on the desktop to begin with are gone!

That's what the typical Windows or Linux power user might expect, but your typical user actually is often unsure about what the result will be from dropping that "photos" folder into a folder that already has a "photos" folder. Honestly, I've been doing some level of desktop support for more than 10 years, and it's one of those things that only *seems* intuitive because you've already been trained to expect it. I continue to have users ask me what will happen if they drag one folder in over to replace another. Many people expect that it will erase the old folder.

I'm not saying that merging the folders isn't a useful function, but let's not pretend that it's the "obvious" and "right" answer. It's just the answer you're used to.

Re:Par for the course?

[nine-times]

Given that I am my Director, I don't think it will be hard to explain it to me.

Re:Par for the course?

[Cro Magnon]

Personally, I prefer merging, simply because there's less potential for data loss. It's easier to manually delete extra files than it is to restore missing ones. It might not be any more "intuitive" but it's safer.

Re:Par for the course?

[DeadChobi]

Expecting one behavior and getting another perfectly describes every experience I've ever had on the Macintosh. Apple didn't just design a computer for people who can't use computers, they've designed a computer that I can't use.

Re:Par for the course?

[CorporalKlinger]

Personally, I prefer merging, simply because there's less potential for data loss. It's easier to manually delete extra files than it is to restore missing ones. It might not be any more "intuitive" but it's safer.

My point exactly. I want my computer to protect my unknowing mother, brother, uncle, or grandfather from accidentally deleting hundreds of important documents. If they click "continue" or "Yes to all" when asked about merging on a PC, the worst they'll do is overwrite photos or documents with the exact same names. In my own technical support experiences, people tend to rename things that are important for them - a thesis may be found on a student's computer with 15 to 20 different names. A Master's project paper may be saved with a few different "version" names. Chances are, merging won't overwrite anything that isn't an exact duplicate, with the way people's minds work and the way they name files when saving important things. And with my photo example - most digital cameras keep a running counter at least from 0 to 9999 with their file numbering system, even after changing memory cards or downloading the pics to the computer. Chances of overwriting old, precious photos are very low with a merge. My Canon handheld camera counts higher than 9999... few people have that many photos in 1 directory anyway. With the "overwrite this folder" option that is the DEFAULT on Macs, one errant click and it not only moves the files, but deletes ALL of your original files. THAT is a problem. Oh, and how do you do a merge copy on a Mac? Open the command line or go into each directory and move the files within them by hand... wow; that's easy and intuitive.

Re:Par for the course?

[MobyDisk]

The term "spatial" is B.S. If I pick up a folder on my desk named "Documents" and I drag it on top of another folder named "Documents" then both folders are there. It neither merges, nor replaces. If I wanted a "spacial" setup I would not have bought a computer, I wold have bought a filing cabinet.

Re:Par for the course?

[Blakey Rat]

No, both a folder and an icon are "objects" and all "objects" in the filesystem should behave the same way. The watchword for a spatial interface is consistency; treating one icon differently from another icon is inconsistent.

Re:Par for the course?

[Blakey Rat]

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.

Yes, but to do that you have to open the folder to take the paper out, right? That's the same thing MacOS is requiring you to do.

Re:Par for the course?

[konohitowa]

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.

That seems about right. OS X 10.0 came out in March of 2001. XP came out in May of 2001. Since then, Apple has released 5 new versions [which have included major updates to most applications, added apps, etc] in addition to myriad "service packs". So, using Apple's petty list multiplier, that would be 1500 new features. In that time, Microsoft has released XP SP2 and Vista. To be fair, Microsoft seems to be in a trend where you go to their website to get new/updated apps or get them pushed via the updater. But most of Apple's 5 releases have also included multiple updates to the underpinnings, frameworks, and the like [I still clearly remember the pain of dealing with the myriad deprecated Frameworks interfaces in the 10.0 .. 10.3 time frame].

Re:Par for the course?

[nuzak]

> Um. What exactly do you think a directory is on every other posix filesystem in the world?

A special file with dirents in it that gets treated specially by the filesystem layer in all the relevant syscalls. Rather unlike HFS.

vi / gives me a dired interface, but yeah, just doing a cat on a directory dumps the raw bits. Well, these days you have to force it.

Re:Par for the course?

[nine-times]

Ok, so you can't use it because *you* expect behavior that's different from what you get on OSX. If you use a given platform for a long time, you get used to whichever conventions that platform uses, and then switching to another can be disorienting. That doesn't make other platforms' conventions wrong, it just makes them, "not what you're used to."

I use Gnome, KDE, Windows, and OSX on a pretty regular basis, and each have their quirks. At least OSX generally avoids prompts like, "Would you like to cancel this operation?" with the only possible responses being "Ok" or "Cancel". In order to replace a folder by dragging and dropping it, you have to click on a button that says "Replace". Pretty clear. I've actually seen users get confused, though, when they dragged one folder into anotherin Windows, got a prompt, hit "ok", and had the folders merge when they actually wanted to *replace* the folder. They weren't even Mac users, they were just novice users.

Personally, I'd like to see three options: Replace, Merge, and Stop.

Re:Par for the course?

[jay-be-em]

Cool, thanks, I looked back over this thread and realized that yeah, I scrambled up the mac/win
responses a bit, my bad.

Re:Par for the course?

[DeadChobi]

I can use Linux with the expectation that the buttons I used in Windows actually work with it. I can't do the same on the Macintosh. I've had numerous experiences using a one-button mouse where it will either simulate a right click or just single-click apparently at random. I've also had issues with the gadgets popping up at random intervals, yet not popping up at all when I try to get them to appear. In Windows and Linux the Ctrl combinations for copying, pasting, and saving are the same across all the programs I've tried.

On the Macintosh they are instead done using the Alt button. This is very annoying. Also, when I press the home key it bounces to the beginning or end of the entire document and not just the end of a line. It's a big turnoff for me that I have to relearn every hotkey and deal with some very unpredictable behavior on something that's supposed to be a highly simplified platform.

If I had a choice, I would not be using OSX, because it's difficult for me to be productive in an environment that doesn't even attempt to understand where I'm coming from.

Just because a standard is De Facto, it does not mean that the standard isn't a standard.

Re:Par for the course?

[solios]

The first OS X to ship - OS X Server 1.0 (and 1.1), which was available long before Public Beta and bore no resemblance at all to the final product - had a Merge command in the Finder.

It was incredibly useful, prevented crap like this from happening, and has never appeared in any release of 10.x. For some damned reason.

Maybe they're saving it for 10.6 or 10.7. :P

Re:Par for the course?

[JunoonX]

...most people don't even know stuff like this exists in Vista, and it is both powerful, easy, and just works. The latter is usually attributed to OSX, actually glad to see something actually works like expected in Windows. I will need less time managing the system than my work.

Re:Par for the course?

[stang]

Do you happen to know a way to give Winamp's autohide feature a slight pause before activating

Sorry, unless you've got access to the source, I don't know of any way to do this.

Re:Par for the course?

[stang]

So instead of having 6 drive letters for the Removable Disk you'd rather it just say Removable Disk 6 times, and when you put in your SD card instead of remembering its X: you just guess which one it is?

No, I'd rather be able to label them.

What I'd really like is for them not to show up unless there's a card inserted. And not have a random drive letter associated with them (but I repeat myself).

Re:Par for the course?

[stang]

Just remount the devices to an NTFS folder and delete the drive letter mapping

Is that going to work for the primary partition, too? And why do I have to do it -- why isn't it a default? App compat (as you 'softies call it) issues?

Re:Par for the course?

[Anonymous Coward]

If I had a choice, I would not be using OSX, because it's difficult for me to be productive in an environment that doesn't even attempt to understand where I'm coming from.

That's OK. You're not making any attempt to understand where the Mac users are coming from either, so it's all fair.

Many if not all of the UI conventions in question were originated on the Mac before Microsoft had an even remotely useful version of Window shipping. You're asking Apple to change things which its users are accustomed to just because something else got popular in the interim.

Re:Par for the course?

[Anonymous Coward]

Unix most certainly merges directories, and doesn't delete them.

Oh really?

I mean, I'm sure that you can find a GUI file manager which does. But I doubt very much that cp or mv does. To get merge, you have to go to rsync, which is historically a very recent thing.

The Mac behavior basically goes back to the original HFS, which technically didn't really have directories at all, just a UI that faked them. A folder was just a file with a list of files in it, so naturally the folder would be overwritten by such operations.

HFS has always had directories. You're thinking of MFS.

And I very much doubt that the behavior was actually dictated by MFS. MFS stored the information for the fake folders in *one* file, not a bunch of individual files. Thus, the Finder (the only application which knew about the fake folders) was always going to be doing significant editing on that file, regardless of whether the behavior was replace or merge.

Nowadays, the fact that MacOS still doesn't even give you the option to move the freaking conflict out of the way with an automatic rename, let alone the merge many people expect

I don't expect a merge. I don't want a merge, for that matter. I use both systems and I almost never run into a situation where a merge is useful.

Re:Par for the course?

[nine-times]

Still, a little perspective is warranted. Some of these conventions are old conventions that have been with Apple for a while. Some of Apple's "non-standard" behavior are conventions that Apple had before Windows, Gnome, or KDE even existed. Just because the behaviors are new to you doesn't mean that they're some new random violation of the "standard".

It's a complicated issue, but in the most simple analysis, Apple created the convention, Microsoft violated it, and Linux DEs copies Windows because Windows was more popular. Apple has in some cases copied Windows's way of dealing with things, and in some cases has chosen not to. But let's not pretend that Apple is just being stupid or contrary. They did it first, and they stayed with their way so as to be consistent, for the benefit of their customers.

Re:Par for the course?

[DeadChobi]

And I'm saying that this sticking to their personal convention is what makes their computers difficult for me to use.

Re:Par for the course?

[nine-times]

Fine. And Microsoft sticking with their personal conventions is part of what makes it difficult for Mac users to use. Big deal.

Re:Par for the course?

[ozphx]

What I'd really like is for them not to show up unless there's a card inserted. And not have a random drive letter associated with them (but I repeat myself).

Thats what my external card reader does. The one in my monitor takes up like H-M or some crap. I'm guessing its typical retarded drivers from shithouse manufacturers.

In fact I'd go out on a limb and say that 90% of Windows shittyness is caused by third party bullshit. 50% of that is due to Realtek.

Re:Par for the course?

[DeadChobi]

Big deal, indeed.

Re:Par for the course?

[TheNetAvenger]

Apple's 5 releases have also included multiple updates to the underpinnings, frameworks, and the like [I still clearly remember the pain of dealing with the myriad deprecated Frameworks interfaces in the 10.0 .. 10.3 time frame].


You have a valid argument, however you are greatly discounting MS's work and inflating Apples.

1) The OS X upgrades are not all full scale OS revisions, many of the OS X series are more about updating things like iPhoto or adding Safari then any substantial OS level changes.

2) MS Supplied a lot of updates for not only problems, but architectural changes in SP2 and also has kept updating OS applications like Movie Maker, Media Player, Messenger, etc.

3) Vista is more a rewrite and has more architectural changes than any other version of NT that came before it. Even going from 3.51 to 4.0 NT was not even a drop in the bucket, and even the large jump from NT 4.0 to Win2K and the new domain and AD systems and architectural changes don't even compare to the changes in Vista compared to XP.

Vista doesn't look a lot different or work a lot different than XP, but that is what makes it more outstanding than people realize, as the OS is using a new network stack, video system, printing system, audio stack, and yet virtually everything still works and just as well as it did on XP, even though everything is running on a different architecture.

Truly take a look at what MS has did instead of 'expecting' more from them. The change from XP to Vista is something they basically pulled off in three years of development, and is 10x the progression they have ever did on any other OS update in their history.

They also should get some props for not only pulling off Vista but maintaining the level of compatibility with hardware and software that they did, as it supports more hardware and more software by a factor of 100x than any other consumer OS. And that is pretty staggering.

If MS only had to work with their own hardware and have more control over the software produced like Apple does, then they would deserve the slapping people are trying to give them over Vista, but when dealing witht he scale they are, Vista is quite impressive that it even runs at all, let alone faster, and more stable than XP.

People also like to talk about security and quality, yet Leopard has had several showstoppers that wouldn't have made it out of MS's automated testing systems, let alone to a retail box. Vista has had no massive data loss cases, or things like the blue screen lockup of Leopard.

Also look at security for the last year, Vista even being a new OS, and already more copies running than all of the OS X sales combined, had less patches, updates, or security fixes than OS X or even XP that it replaces.

Just take a breath and try to look at both sides of the coin. You don't have to hate one side to like the other.

Take Care...

Re:Par for the course?

[mooncaine]

Amen to that, brother. It's quite frustrating, just trying to merge the contents of 2 identically named folders. It makes working with 2 or more Macs a pain, and that's unnecessary, because they could just add a damn option in Finder for those of us who care: "Merge identical folders on destination instead of overwriting"....

Re:Par for the course?

[evalencia1]

It might be inconsistent, from your point of view, but you have to deal with people's expectations. As I said, people care about what is in the folder, not the folder itself. So what if you "treat one icon differently"? The point of a filesystem is to storage of their files, not consistent treatment of icons. Losing files you didn't expect to lose - bad. Having files from same-name directories mixed together because you moved files from one location to another - possibly annoying, but less painful.

The "merge" behaviour is the one that's consistent with the real world, which is really the starting point for the desktop metaphor. If I have a folder labelled "bills" on my study desk, and then put it on another table with another folder also labelled "bills", I don't lose the contents of the first folder. The contents of both folders are still there.

Re:Par for the course?

[amliebsch]

I don't know if it works for the primary or not; I suspect not. Why isn't it default? Because at some level, an arbitrary naming convention is required for logical disks. Linux uses hda1, hda2, hdb1 and so on, Windows uses C: D: E: etc. Either system is arbitrary and can be modified, and the Windows one has been around for long enough that people are familiar with the convention.

No Big Deal

[Mordaximus]

This is exactly why they release Time Machine at the same time! :)

Re:No Big Deal

[Anonymous Coward]

You have to think that if Apple is not able to get mv right, will you trust them in getting time machine right?

Easy workaround

[Anonymous Coward]

Just point Time Machine to a network volume before copying any files and you are all set.

Unless you lose the share in which case you're screwed.

Take advantage of Time Machine

[tji]

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.

Re:Take advantage of Time Machine

[radish]

"We can't write code that reliably moves a file between two points, but don't worry - you can rely on our brand spanking new magic backup solution to save you - it's bug free!"

Errr....yeah :) Smartass comments aside, I believe time machine only does things every hour or so, right? So still the potential for severe loss.

Re:Take advantage of Time Machine

[nuzak]

> This would be a great demonstration of the value of "Time Machine" backups.

Yeah, but it would also be a great demonstration of how the competition doesn't have this behavior at all. If my main chute tears like a nylon stocking, I'm not exactly one to trust the backup chute made by the same people, dig?

Re:Take advantage of Time Machine

[Anonymous Coward]

It's actually every 10 minutes.

Any data loss is severe. But, that's the point of backups, to make sure the loss is minimized.

Re:Take advantage of Time Machine

[Just Some Guy]

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.

When I was backing up with Amanda, I had a correctly-named directory called "Not Backed Up". I'd put large projects in there and made aliases whenever necessary for convenience. Just an idea.

Re:Take advantage of Time Machine

[dropadrop]

Same thing applies to any large file, such as a VMware VM file.

You are right, it would be better. But in the meantime you can take a snapshot of the virtual, then only the changed data will be backed up.

Nothing to see here, folks

[ciaohound]

Honestly, who is using Finder anyway? Why wouldn't you just open Terminal and use cp and rm? Sheesh.

Re:Nothing to see here, folks

[Knara]

I know you're trolling/being sarcastic, but just in case anyone is tempted to agree with you, the answer is "almost every person using OS X". (even though Finder is really friggin annoying)

Re:Nothing to see here, folks

[Nazlfrag]

Sure, just whatever you do, don't use mv.

Youth

[headkase]

With software being in it's infancy relatively compared to other engineering disciplines, I can't wait to see what an OS is going to look like even twenty years from now... much less fifty.
I thought AmigaOS was the sh*t way back when so already I'm impressed even with bugs.

"Doing it the apple way"

[jgarra23]

hehe... sorry, I just love that quote. This is apparently how move works in "The Apple Way". The same thing can happen to your bank account when purchasing Apple products... flame on, troll, whatever lol...

Not that I engage in schadenfreude all the time but I feel a little warm feeling inside that makes me smile when those jerks @ the PDX Apple store have their cake and eat it too. Try n' make me feel like they're doing ME a favor by selling me an ipod... sheesh...

Wow

[Zebra_X]

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:Wow

[Tack]

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. Indeed this is what it does.

I'd call this a bug. (The wording of the dialog, that is.)

Re:Wow

[Zebra_X]

Good to see Linux is sane too... :)

Re:Wow

[Tack]

Figured I should file it: http://bugzilla.gnome.org/show_bug.cgi?id=493964

Re:Wow

[Blakey Rat]

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.

From the user's perspective-- if they're a Windows user!

From the Mac Classic user's perspective, OS X just does what you'd expect a spatially-designed interface to do, treat every object the same. If you drag a Word file over a Word file with the same name, it asks if you want to replace it. Ditto folders with the same name.

The problem is that OS X still has that behavior even though it's no longer spatial at all. Since it's not spatial, it might as well do what the Windows/Linux users expect it to do and save some headaches.

Re:Wow

[Inf0phreak]

Apple has AFAIK for a long time (always?) subscribed to the philosophy that folders in your computer should mimic paper folders. In particular, when you come with a folder named "Documents" and you already have one named "Documents", the "paper way" to handle that is to throw one you have in the shredder and put the new one in its place.

You can argue that this is retarded and I'd agree with you. That design decision has probably caused much more data loss than the bug in TFA ever has or ever will, but it's The Apple Way(TM) and it's not likely to change. Ever.

Re:Wow

[JonathanBoyd]

Why on earth would that ever be the default option for a directory move?

It's always been the default on the Mac.

The overwhelming majority of times I've copied a directory, I've been looking to replace, rather than merge. I can see how merge would be useful and arguably a better default, but the current (And historic) default isn't insane.

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

Yeah, I wouldn't be calling anyone insane if you don't bother reading the helpful warnings they give you.

Re:Wow

[nuzak]

I've actually had jobs doing honest to goodness filing, as an intake secretary while doing social work (a weird time for me for sure). Every time I got a stack of case folders, I was generally expected to merge them with any existing folders. Sure as hell not destroy the old ones.

Re:Wow

[Anonymous Coward]

I'd call this a bug. (The wording of the dialog, that is.)

It's also buggy IMO, because it behaves so very differently from the command line

mv A B

(Note this will as expected with an empty folder, but simply fail otherwise.)

Surely only intuitive behavior would be to kludge the old dir with the new (that's what your saying by moving the folder instead to the files it contains, no?. Merging you'd expect it if you dragged all the files from A (as opposed to the folder itself) and put them in B/A. Sounds to me like the Mac is the most intuitive here.

Re:Wow

[MichaelSmith]

From the Mac Classic user's perspective, OS X just does what you'd expect a spatially-designed interface to do, treat every object the same. If you drag a Word file over a Word file with the same name, it asks if you want to replace it. Ditto folders with the same name.

Why? On my physical desktop objects with the same name can coexist. In OpenVMS coping [dir1]A.A over an existing [dir2]A.A will leave two files [dir2]A.A;1 and [dir2]A.A;2 in the target directory. And incidently, in the same OS rename will not work across volumes. You have to do backup/delete which definitely backs up and then deletes.

Why should MacOS demand that file names be unique? Windows and Gnome rename files on paste if there is a name conflict. Why not do it on a drag? For me it makes sense that only the delete function should be destructive. If you must blow away the replaced file why not put it in the Trash?

Re:Wow

[p0tat03]

From the Mac Classic user's perspective, OS X just does what you'd expect a spatially-designed interface to do, treat every object the same.

Sometimes designing by philosophy is a bad idea. A good file management paradigm should never get in the way of doing what users want and expect. If your little file management philosophy does something clearly most users do not expect, then it's not a very good philosophy now is it?

I'm a Mac user and even I know this type of shenanigans are bull. This is Apple refusing to get with the times, nothing more and nothing less. This should have been fixed in 10.2, and we're sitting here with 10.5, with the same problems.

I'm glad to see many file management front-end improvements in Leopard. It dismays me to see that the backend is still as shoddy as it's ever been.

Re:Wow

[Anonymous Coward]

The finder asked me something, I clicked OK.

I realize you're probably a windows user, so maybe you're used to ignoring dialogs, but is it too much to ask for you to LEARN TO FUCKING READ?! OS X usually asks you something if it's important, as opposed to some other OSes that we know that ask you for everything. Although admittedly, there have been instances of OS X bothering you about some things more often lately with trivial dialogs (file extensions, etc.), but in this case it certainly isn't one of them.

Re:Wow

[Blakey Rat]

Sometimes designing by philosophy is a bad idea. A good file management paradigm should never get in the way of doing what users want and expect. If your little file management philosophy does something clearly most users do not expect, then it's not a very good philosophy now is it?

I dunno. As a Mac Classic user, it does exactly what I expect. It all depends on what system you're used to. It might be true that "most" Mac OS X users expect merge to be the default action (being converts from other OSes), but I don't have any data to back that up.

I got the nerd-street-cred of being a Mac user from System 6.0.8, so I'm not exactly the typical case. (I'm still more likely to complain when Windows/Linux does something boneheaded I don't expect, like just beeping at me when I hit down-arrow at the bottom line of a text field instead of moving the cursor to the end of the line.)

Still, I entirely agree that it's moronic for Apple to cling to little bits of the spatial GUI philosophy if they're going to flush the majority of it down the toilet. Let's see all or nothing, Apple, stop this straddling.

Re:Wow

[jyoull]

No.

I would expect a true "spatially-designed interface" to not only behave that way, but also to allow me to even have multiple files with the same name in the same place if i wanted to. The file name is not the object. It's just a label for the object.

But the spatially-designed interface should not allow me to place two objects in the same place. Done right, clever designers would then implement "layers" so the objects could identify the same XY location but on different planes.

yay.

Re:Wow

[Anonymous Coward]

There's no street-cred in being a long-term faggot.

Re:Wow

[martinX]

In which case what you were doing was opening the folders and merging the contents. This is exactly what happens with MacOS: if you open a, say, Documents folder, and attempt to move everything inside it to another open Documents folder, the contents will be merged with questions asked about files with identical names.

There is no inconsistency. Move a folder to somewhere with a folder that has the same name, this will potentially (if you agree) replace the folder. Move the contents, merge the contents. Just like Real Life.

Re:Wow

[VGPowerlord]

(Note this will as expected with an empty folder, but simply fail otherwise.)

Simply fails? I guess this depends on which mv you're using. I don't know about BSD mv, but GNU mv with two directory arguments moves the first directory into the second.

Re:Wow

[nuzak]

Yeah, it's exactly what happens with MacOS, if you do something completely different than what was described. Just redefine reality until Apple is right, and the rainbows will still sing happy tunes.

Re:Wow

[Anonymous Coward]

Correction: You didn't click "OK", you clicked "Replace." Probably because Windows has taught you to ignore the information in dialog boxes and just click the button.

What you consider to be an obvious defect I've always considered to be a feature. After dealing with Unix and Windows for 10 years and never getting the results I expected on a copy/move operation, I was delighted to find that Mac OS X behaved as expected. In 8 years of using a Mac I've never suffered any data loss because of this behavior. I rarely find a need to merge folders, but in those rare cases where I do want to do it, I agree that it would be nice to have a "merge" option, though I would be against having this as the default.

See also: http://lowendmac.com/misc/05/1031.html

Re:Wow

[amliebsch]

Windows and Gnome rename files on paste if there is a name conflict. Why not do it on a drag?

Interestingly, Vista presents you with the option to do just that - rename conflicting files on a drag/drop merge.

Re:Wow

[Chaset]

Replace "sane" with "used to Windows".
I actually had the opposite problem when I was getting used to Windows. I hand a folder with bunch of files I didn't want, and a folder with the correct files in it. I expected a replace operation (because that's what Windows would do with any other kind of file) but instead I got a folder with a mix of bunch of files I wanted and buch of files I didn't, forcing me to sort through them to figure out which was which.

A merge operation is useful, but from my perspective, it shouldn't be the default.

Re:Wow

[itsdapead]

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

I think the designer's intention was that you should read the warning before pressing OK. PEBKAC.

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

Ignoring philosophies about "spatial design" the more pragmatic justification is that the Mac method produces a predictable result whereas the "merge" method leaves you with no clue about what has been added or replaced in the destination - and if something stops the copy half way through (often something non-catastrophic like a file permission) then the destination is in a totally indeterminate state. Merging directories really needs a proper "sync" tool.

TFA sounds like something that should be fixed, though - even so, "don't do that then" is pretty good advice, just copy & then delete the original - hardly rocket science. (I don't suppose the "missing" files simply got moved to the Trash?)

Re:Wow

[Cro Magnon]

Windows and Gnome rename files on paste if there is a name conflict.

The only time I've seen XP rename on a paste is when I'm copying in the same directory. When I copy from one directory to another, it just asks if I really want to replace it. Vista does give you the option of renaming, and I think KDE does too.

Re:Wow

[Culture20]

But you had your data to sort through. Without a backup GP lost data. There should be a blatant warning that files are going to be removed from the filesystem during a simple move operation.

Re:Wow

[mindstrm]

In your case they only have the same name if you ignore the wonderful "version" that VMS provides... which is more or less part of the filename anyway for practical purposes.

Re:Wow

[Anonymous Coward]

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

If your intention was to move the files and not the folder then why did you move the folder? MacOS is not Windows so expecting it to work like Windows is retarded. Not reading the dialogs is retarded too, especially when you're dealing with data.

If I have ~/foo.jpg and drag a file named foo.jpg into ~/ then the OS assumes I want to replace the stationary file with the moving one. It works the same way with folders, always has, and it's likely that it always will work that way. As far as the OS is concerned there's no merge for jpegs like there's no merge for any other type of file or folder.

If I want to merge two folders then I select the files I want from the first folder and drag them to the second folder. Simple, sane.

Re:Wow

[The_reformant]

The only reason replacing the directorey makes sense is if you know something about filesystems, that you know a directory is just that, a directory of addresses keyed on filename.

A normal user these days knows about folders, not directories. This is a metaphor using a real object to abstract the process of dealing with their data. In the real world when you move one folder to another folder it is most definately NOT a destructive operation so why should a user expect a destructive operation from the underlying filesystem?

Although on the other hand of course in the real world there would be nothing to stop you putting 2 folders with the same name inside a parent, it probably wouldnt be that sensible to carry over that idea.

Re:Wow

[Anonymous Coward]

If I was you I would first think of better naming conventions for your directories. Personally I prefer 26-digit hexadecimal names - 30A239FC32176BD3A8ED334BA1 - simple, straight to the point, and easy to use.

Re:Wow

[Smurf]

Without a backup GP lost data. There should be a blatant warning that files are going to be removed from the filesystem during a simple move operation.

Ah, you didn't read the GP post carefully. Let me quote him:

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

So he acknowledges that he received the kind of warning that you are asking for. Furthermore, the actual text of the dialog is:

An item named "C" already exists in this location.
Do you want to replace it with the one you are moving?
                                        (Stop) (Replace)

The GP actually clicked on a button that said REPLACE!

Hmm... it seems some people need reading comprehension classes here... ;-)

Re:Wow

[bar-agent]

There's no street-cred in being a long-term faggot.

Depends on the street in question, I'd say. Certain neighborhoods in Seattle and San Fran. spring to mind...

Re:Wow

[Zebra_X]

Give this man a prize - I think that's the best answer I've heard so far...

Re:Wow

[DJSpray]

I'm sorry, but I just don't understand. You think it is _intuitive_ that if you drag an object (a folder) into a window representing a folder, and it has the same name as a folder that already exists, the two should be magically _merged_?

OK, now you've got an instant version control problem. Was the destination folder (the one you merged into) the canonical one? Was the source folder the canonical one?

With merging, you didn't lose anything, but now you have two folders, the original and the merged, that don't match. How does that help anyone keep their files organized?

Replacing isn't the default behavior -- that's why it asks you if you really want to do it.

You wrote "from the user's perspective you aren't really moving the directory, the intent is to move the files." Why do you think that? You've got to understand that most people -- including most computer users -- don't actually understand hierarchies, and never will. The icon == the directory. And that is what they are moving. Just as a physical file folder (the original metaphor, originally somewhat strained) is not the papers inside.

Ah, the "outsourcing" coding model..

[eniac42]

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

Re:Ah, the "outsourcing" coding model..

[Anonymous Coward]

mv $from $to

Now, where is my $10?

Re:Ah, the "outsourcing" coding model..

[BKX]

That would still have the same problems. Try 'cp $from $to && rm -r $from'.

Re:Ah, the "outsourcing" coding model..

[Larry Lightbulb]

rm $from Now where is my $5?

Re:Ah, the "outsourcing" coding model..

[lgftsa]

Kiss goodbye to your subdirectories and hidden files, then there's those nasty spaces and shell escapes, and... OK, I'll stop now, there's too many things to guard against. Using rsync and a wrapper to parse the arguments comes close, but there's still problems with "illegally" named initial files and directories.

Re:Ah, the "outsourcing" coding model..

[megaditto]

Don't you mean

cp $from $to || rm -r $from ?

Re:Ah, the "outsourcing" coding model..

[beav007]

Um... no. REALLY no. Please don't do that.

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:Ah, the "outsourcing" coding model..

[megaditto]

And that's probably why you don't work for Apple!

Re:Ah, the "outsourcing" coding model..

[Brian Gordon]

Please, it's all about branding. They have to have a move in there somewhere. Ergo:
mv $from /dev/null

Re:Ah, the "outsourcing" coding model..

[Anonymous Coward]

Which UNIX variant allows you to mv files to /dev/null in order to delete them?

Re:Ah, the "outsourcing" coding model..

[Magic5Ball]

Not FC6, appearently...

[root@alpha tmp]# echo "foo" > file
[root@alpha tmp]# mv file /dev/null
mv: overwrite `/dev/null'? y
[root@alpha tmp]# ls -al /dev/null
-rw-r--r-- 1 root root 4 Nov 5 14:17 /dev/null
[root@alpha tmp]# cat /dev/null
foo
[root@alpha tmp]#

Re:Ah, the "outsourcing" coding model..

[NoNickNameForMe]

>The syntax for "||" is:
>If command 1 fails, do command 2 - otherwise exit (where you used "command1 || command2").

But that's exactly what the Leopard Finder is doing!
Maybe he's the Leopard Finder's coder?

Re:Ah, the "outsourcing" coding model..

[fractoid]

All about branding hey?
alias iMove mv

Re:Ah, the "outsourcing" coding model..

[BKX]

Actually I meant this but posted too soon. It pretty much guards against most things (the shell will do all the escaping necessary). The only thing i foresee a problem with is if names that are legal on one filesystem that are illegal on the other. I don't think rsync takes care of the either.

cp -aRp "$from" "$to" && rm -r "$from"

Re:Ah, the "outsourcing" coding model..

[Brian Gordon]

Which operating system uses the trash bin to burn discs?

Re:Ah, the "outsourcing" coding model..

[rizzo320]

Which operating system uses the trash bin to burn discs?

That's just one of several ways to burn a disc in Mac OS X. You can also:

1. Click on the disc on the desktop and then go to the File menu and select "Burn Disc", or...

2. Double click on the disk, review its contents in a Finder window, and click the "Burn" button, or...

3. Right-click (or command click with a pesky one button mouse) on the disc and select "eject disc". If you have copied any files to the blank disk, it will ask if you want to burn it. If you haven't, it will eject the disc. This is the same procedure as dragging the disc to the trash (which starts the eject disc process).

Personally, I think triggering the burn process by dragging to the trash is a good idea. If you start to compile a disc, and forget about it, you will be queried to burn that disc upon attempting to eject the blank disc. It's good that there are several different, convenient ways to burn a disc in Mac OS X. So yeah, I'm happy it uses the trash to burn discs. Aren't you?

Re:Ah, the "outsourcing" coding model..

[CaptnMArk]

For the paranoid, check if $to is a subdirectory of $from.

If you're lucky, it will take forever and then delete all your data.

Re:Ah, the "outsourcing" coding model..

[space_in_your_face]

But that's exactly what the Leopard Finder is doing!
Not exactly. The Leopard finder is doing something like:

cp "$from" "$to" ; rm -rf "$from"

like in "remove $from regardless if the copy was successful or not".

Re:Ah, the "outsourcing" coding model..

[Programmerman]

Syntax is actually exactly the same in Windows, except it's "copy" and "del" instead of "cp" and "rm". I really do need to stop trying to use "rm" in Windows, though.

Re:Ah, the "outsourcing" coding model..

[orgelspieler]

According to the blog comments it's just a problem with Finder (Apple+drag); using the mv command does not exhibit the bug. I don't have my Mac handy, so I can't verify.

Re:Ah, the "outsourcing" coding model..

[Em Adespoton]

You might also want to point out that when you drag a disc to the trash bin, the icon changes from a trash bin to an eject icon (the same one on the eject key on Apple keyboards) and the "Eject CD" tooltip comes up. Personally, I figure that the only reason Apple didn't re-map this function to "erase CD-RW" is that historically, dragging to the trash bin has always ejected removable devices (it did this 20 years ago with single sided floppies). Even though the original concept is flawed, the concept of writing data to the disc before completing the eject process does make perfect sense.

Re:Ah, the "outsourcing" coding model..

[lazarusdishwasher]

filesize=`ls -l $from |awk ' {print $5}'`
while ['diff -a $from $to']
do
    dd bs=$filesize if=/dev/random of=$to
done
rm $from

Re:Ah, the "outsourcing" coding model..

[Malevolyn]

You could always get UNX Utils.

Re:Ah, the "outsourcing" coding model..

[mikiN]

Grumpy Grandpa Unix Guru once said:

$ (cd "$from" && tar -cf - .) | cat | (cd "$to" && tar -xpf - && cd "$from" && rm -rf .[^.]* *)

(assumes: $from and $to are absolute paths to directories)

Sometimes the "old ways" aren't too bad.

My Mac sucks

[sootman]

The original submission:
I don't want to start a holy war here, but what is the deal with you Mac fanatics? I've been sitting here at my freelance gig in front of a Mac (a 8600/300 w/64 Megs of RAM) for about 20 minutes now while it attempts to copy a 17 Meg file from one folder on the hard drive to an SMB share that disappeared...

Every System have critical bugs

[El Lobo]

but NEW system have even more bugs. Every new system have children diseases: some simple bugs, cosmetical, but also critical. A modern OS is a VERY complex thing, and Abbles MakOS is not different.

I guess, more bugs are to be revealed when the number of users continue to rise, but they will also be fixed, so the system will become more and more stable with the time.

The difference is, how the media and people in general reacts to an error of such a kind. Could yu imagine what people would scream and cry is Vista happened to just loss a bite of information? Oh, christ, I don't want to even THINK about this. Now, Abble, does that mistake, and... that's OK, nobody is perfect... Will get fixed.... People have double standards, but in the end, Vista was not THAT bad, and Abble's OSX was not THAT good. The true, is as always there, somewhere in the middle.

Re:Every System have critical bugs

[Anonymous Coward]

Macrofluff Pissa still sucks without even losing a byte.

Re:Every System have critical bugs

[JonathanBoyd]

Abbles MakOS ... Abble, does that mistake ... Abble's OSX

Irony, meet El Lobbo. El Lobbo, meet irony :^)

I agree with the points you're making, but feel compelled to point out an error of your own: it's Apple's Mac OS X. We get a bit precious about the way it's written sometimes.

Re:Every System have critical bugs

[largesnike]

I agree with this speaker. I am a long-time Mac user, and have used Windows through 3.11, 95, 98 2000, XP, but not Vista, and have used Ubuntu and the Fedora distros. I would say that, in my humble experience the user experience on OS X is slightly better than the others, while its performance (again from a user perspective) is comparable to most Linux distros that I have seen, while somewhat better/more responsive than Windows (on the whole).

I think it has a good future, especially as it migrates though Cocoa APIs, it's got setbacks, like its reliance on Objective C.

It's not magic, and to the average abacus user in the middle ages all OS's will be similarly bewildering, but it is nice.

Not a fanboy, but I do appreciate it.

Re:Every System have critical bugs

[Jm_aus]

You're not a developer; you're obviously a technical writer.

Re:Every System have critical bugs

[rbanffy]

Sorry to tell, but a data loss error is unjustifiable. And OSX is not that new an OS to make us expect something like this. When you move a file be damn sure to check if the files are really there (invalidating caches - I suspect excessive caching could be the cause of the problem) _before_ you delete the originals.

"A happy Windows user and developer, And PROUD of it!"

That kind of explains the low expectations.

Re:Every System have critical bugs

[VGPowerlord]

"A happy Windows user and developer, And PROUD of it!"

That kind of explains the low expectations.

That reminds me of Lowered Expectations from MadTV.

No it isn't

[gcnaddict]

Apple beta tests software through the AppleSeed program. You have to pay to be able to participate in the program (What? Don't most companies pay the people that test their software?).

There aren't nearly as many AppleSeeders than there were free Vista beta testers for instance. This is why Vista has no data loss bugs. The sick bugs are more likely to get caught when there are more testers.

Re:No it isn't

[tf23]

You have to pay to be able to participate in the program

Wrong-o!! You absolutely do not have to pay anything to involved in the Appleseed program.

Re:No it isn't

[webmaster404]

Thats when you realize that open-source code is the way to go. Why? Because someone will look at the code as long as its a critical program to the system. This is why Linux and other Open Source programs have minimal bugs and when they do, they are quickly fixed whereas a "service pack" for Windows takes a year or two and about three years for the next version of OS-X. But, if only the code was open, oh well, I guess Ill just stick to Linux....

Re:No it isn't

[WGR]

Funny, the part of OS-X (Darwin) that does file copying is open source, so I guess you have already found the bug and told given Apple the fix.

Source Code being open is no guarantee against bugs, it just means that more people can search for them.

Re:No it isn't

[webmaster404]

I honestly wouldn't call Darwin Open source, because you have to enter just about everything about you including your address just to download a copy, if it was truly open-source it should be downloadable on a public FTP server, sure you can get the source, but hey, I don't own a mac and when its a hassle to get the source code, why bother, just get BSD and put a Mac skin on GNOME or KDE.

Re:No it isn't

[poopdeville]

Bullshit. http://www.opensource.apple.com/darwinsource/

Re:No it isn't

[tftp]

Someone already mentioned that the bug is not in copy or delete functions of the kernel - it is in the Finder GUI that is not open source.

Re:No it isn't

[JEB_eWEEK]

Not quite.

How can I sign up for this program?

We are not seeking new participants. You must have an invitation in order to log in.

https://appleseed.apple.com/cgi-bin/WebObjects/SeedPortal.woa/wa/faq

OR, there's:

Become an ADC Select Member US$499.00

Upon purchase and activation, you'll receive:

* ADC Software Seeding Program

http://developer.apple.com/products/select.html

Re:No it isn't

[jcr]

ADC seeding and customer seeding are not the same thing. Different departments, different purposes.

-jcr

Re:No it isn't

[Anonymous Coward]

Wrong-o!! You absolutely do not have to pay anything to involved in the Appleseed program.

The free developer programs do not include seed access. <rant>It's bad enough that someone who doesn't know what he's talking about posts misinformation; but other people who are equally ignorant of the subject using their mod points to mod your post up???</rant> Sheesh...

Re:No it isn't

[jeremyp]

The Finder is not open source and the problem is in the Finder.

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.

Re:No it isn't

[Anonymous Coward]

To the mods: calling someone's bullshit is not flamebait. This is flamebait: moderators are fucking retarded.

Re:No it isn't

[tepples]

ADC seeding and customer seeding are not the same thing. Different departments, different purposes. Then where's the invite code spooler for customer seeding like there was for Gmail?

Re:No it isn't

[tf23]

Oh most knowledgeable AC, who must know more about something that which I may or may not participate in (ahem, for free) please take it and stuff it. You have no basis to claim I don't know what I'm talking about. And you post anonymously, so your credibility is just overwhelming.

Nothing...

[Anonymous Coward]

Nothing for you to see here. Please move along. Oh wait...

I don't understand

[DarkOx]

Move is usually a destructive operation, on almost every platform I have ever used. Here are my experiences

Target diskete failure doing a move from C: to A: on DOS, yep your data is gone.

Network error moving from one windows box to another, yep your data is gone.

NFS write failure on Linux 2.4, check your data is gone.

Maybe move should be implemented as copy, completly then delete but its often not. I don't think there is any convention that demands it be that way. If you care about the data, at all you should always copy, check(maybe cursory, maybe md5 depending on how much you care) then delete.

I tell my users all the time, "move it only if you can lose it."

I don't think this is really a "bug" so much as a behavior, ie there is no handling of media exceptions when doing a move. Now if you data sometime went bye bye with two working devices that would be bug, and that is not what is being described here.

I don't think its fair to single MAC OS out for this either. As far as I know most mainstream OS seem to handle move operations with media exceptions badly. I am also not a MAC appologist. I don't have nor have every had any Apple products. Sure maybe the OS should copy, check at least no exception events happened durring and then delete but its not a bug. I don't think you can blame the OS for problems when the hardware under it be it a disk, NIC card, or memory flakes out. If it handles it gracefully then that is a virtue of the system, if does not handle it then its room for improvement in terms of features but not really a "bug".

Re:I don't understand

[EastCoastSurfer]

I don't think its fair to single MAC OS out for this either. As far as I know most mainstream OS seem to handle move operations with media exceptions badly. I agree. I always copy then delete, especially when dealing with network shares. Windows used to lose data if anything went wrong when moving something across the network. I don't have a Vista box handy to test if it is still an issue.

That said, I've never understood why move isn't implemented as a copy, check, delete and only be destructive before completing if the move process figures out you don't have enough space and then prompts you.

Re:I don't understand

[Knara]

Let's think about this. I'm copying a folder called A,B,C, and D from a local volume to a Samba share. I start copying, I get "A" and "B" to the share, and then the Samba connection drops. I should expect A,B to be on the remote share, and C,D in the local volume.

In this current OS X implementation, what I get is A,B on the remote share, with C and D vanished, because OS X deleted the pointer to the folder on the local volume.

This is not sane behavior which certainly doesn't happen on any recent release of Windows, and I'm also reasonably certain it doesn't happen on recent versions of any Linux dist I've used.

Re:I don't understand

[Jasin Natael]

Actually, that's wrong. According to the article, the way this bug manifests itself is that it treats file "C" as having been copied, when it actually was not committed to disk. If I understand correctly, the only file you lose would be "C" ("A,B" on the remote share, dir containing "D" on local), as it is apparently marking files for deletion as they enter the outbound I/O queue (the copy begins), instead of when the copy completes.

Re:I don't understand

[__aagmrb7289]

I don't understand - I've had network problems occur tons of times when moving files (ever had a VPN connection crap out over a long transfer? I have - a LOT), and all that happens is I start the move again. I don't lose files - those that made it are here, those that didn't are still there. So what are you talking about?

Re:I don't understand

[myowntrueself]

I agree. I always copy then delete, especially when dealing with network shares.

Despite its many shortcomings, Windows ME (*NOT* the more recent ME2) had this truly wonderful feature where if you delete something from a network share it would *copy* the data across the network into your trash folder.

Really handy when you delete 10G of data on a network share and your local hard drive has 5G available and you are on a 10mbps network.

Re:I don't understand

[sponga]

Vista implements the copy first when dragging a file to another folder, a little difference I have noticed since XP.

Re:I don't understand

[Knara]

Take a look again at the article. The root folder of the files queued for moving (in my example, it'd be the folder with A,B,C,D in it; in the article it's called "test") disappears from the desktop because the move operation nuked it.

Re:I don't understand

[CaseyB]

I call bullshit on Windows and Linux, and I'm pretty sure you're wrong even for DOS.

Maybe move should be implemented as copy, completly then delete but its often not.

Why on earth wouldn't you? Doing it any other way is not only obviously dangerous, it's far harder to implement! What would you do, map the file on disk, unlink the file and then copy and wipe each raw disk block? I could see doing something crazy like this in specialized applications, where freeing storage at the source is priority one, but in the general case it's insane.

The Apple issue is clearly just a stupid exception handling bug.

Re:I don't understand

[t35t0r]

NFS write failure on Linux 2.4, check your data is gone.

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:I don't understand

[Anonymous Coward]

Hell, it even mentions it works this way in the man file for mv.

Re:I don't understand

[crabpeople]

"Network error moving from one windows box to another, yep your data is gone."

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

[Anonymous Coward]

You're an idiot. I have been using Linux for 15 years. I have had network shares die and even drives die while moving files in Linux and not once have I lost the originals.

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

Re:I don't understand

[Anonymous Coward]

Are you sure? I was under the impression that with a move operation the data didn't actually move but instead the destination directory had a new inode added to it and the source had that inode removed. (for ext2/3 anyway)

Re:I don't understand

[SaDan]

That would work if you intend to keep the file on the same physical filesystem. Moving the file to another physical filesystem, drive, or network share will copy the entire file, then delete the original.

Re:I don't understand

[Mazin07]

No, this is moving across filesystems, in which case the OS has to copy every byte of the file to another physical device. GP is saying that Linux's mv command will not cause you to lose data if the destination does not receive it completely and your original is also naively deleted.

Re:I don't understand

[seek31337]

try doing hundreds of small files that are under the buffer size.

Re:I don't understand

[Anonymous Coward]

Move is usually a destructive operation, on almost every platform I have ever used. Here are my experience.

wrong bitch.

$ mv -v test.txt /media/e/
`test.txt' -> `/media/e/test.txt'
removed `test.txt'

you're talking out your ass

Re:I don't understand

[Emetophobe]

From my experience with Windows and Linux, move is always a copy operation when moving files/folders across partitions or drives. So in those cases, move is never a destructive operation since it's actually copying, not moving.

Re:I don't understand

[Captain Segfault]

linux caches writes to floppies until umount

The nasty case here is that, as far as mv is concerned, the write is complete as soon as it's done writing to cache.

Your test of interrupting the mv in the middle doesn't hit this case because mv hasn't finished yet. If the cached write then fails there's nothing it can do. Unless mv uses uncached writes or does a sync you're gong to have this sort of problem.

Re:I don't understand

[tftp]

Better to look at the generic case. Move deletes the source when the target filesystem (!) reports success. mv has no way to double-check, and the target can be remote. If you do not like lazy write then disable it.

Re:I don't understand

[mpeg4codec]

linux caches writes to floppies until umount

This occurs when the file system is not mounted with the sync option [which is the default, unless there is something in the fstab that says otherwise]. Most modern Linux distros I've seen have an entry in the fstab with something along the lines of noauto,rw,user,sync. That way, an ordinary user who has read/write access to the floppy device node will be able to mount and unmount it, and it will auto-sync as soon as files are copied.

A sibling post mentions that the default non-sync behaviour can lead to the mv problem that the article boils down to. Perhaps you should make sure you mount your external media with sync just to be sure there won't be a problem.

Re:I don't understand

[Anonymous Coward]

I don't know what kind of people think this piece of crap is insightful.

Re:I don't understand

[Anonymous Coward]

I'm copying a folder called A,B,C, and D from a local volume to a Samba share. I start copying, I get "A" and "B" to the share, and then the Samba connection drops. I should expect A,B to be on the remote share, and C,D in the local volume.

Actually, if you're copying you should expect to have A, B, C, and D on the local volume, and A,B on the remote share.

As it happens, many people don't even know how to invoke this bug. I'm an everyday Mac user, and I didn't: I never use move across different volumes, so I actually don't even know the modifier key to press to force the Finder to move instead of copy. By default, the Finder copies when you drag things to a different volume, and moves when you drag them to a different location on the same volume. The only way I ever try to override that default behavior is when I want to make a copy on the same volume.

I couldn't really tell you why I behave that way; it just doesn't make sense to me that you would want to delete the originals until you're sure everything's OK. I'm not even comfortable with the notion of delete-as-you-go on a move operation; it's easy to construct scenarios when copying to a network share (especially NFS) where Computer A thinks it's copied File XYZ to Computer B, but really the last block didn't quite get copied when the network cut out, and now you have a corrupt copy on B and nothing on A.

But then, I'm the sort of person who wants to perform full readback verification on any substantial amount of data before deleting the originals. Paranoid? Yeah, but you would be too if you read the specifications for read error rates on hard disks these days. The disks are getting larger and the error rates are actually getting a bit worse, to the point where reading a whole disk a few times is almost certain to result in at least one read error undetected by the disk. That puts the probability of silent corruption uncomfortably high for me.

How Dare You

[Anonymous Coward]

Sir, how dare you complain of flaws in OSX? No doubt this "bug" you speak of is actually a feature. John Gruber will set us straight soon enough.

Re:How Dare You

[Jaerin]

How about Ed Gruberman?

News Headline

[Anonymous Coward]

Apple employes monkey's to make their Leopard

Apple Customer Quality Feedback (CQF) Program

[SinceEBCDIC]

If it's true that Apple's products seem less-tested these days, it's because they've tossed lots of seasoned customer quality-assurance testers to the wayside.

Many years ago, think System 7, Apple had this great Customer Quality Feedback (CQF) program. We tortured our systems between the alpha-testers and the great unwashed masses. There were Apple staff who (gasp) listened to our bug reports and got back to us reasonably quickly. It was grand.

Then someone got fired, or promoted, or whatever, and the CQF program got lost in the shuffle. Every few years I get an email from someone at Apple telling me that they're reconstituting it, but nothing ever comes of it, and - you know - it's hard to understand how they can ignore a free, highly-motivated bunch of fanboys.

Thread bug?

[mveloso]

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.

Re:Thread bug?

[Anonymous Coward]

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?

More likely the Heisenburg compensators are degrading due to leakage from the EPS conduits. I think increasing the frequency to 8.97 THz should stabilize the field until the positronic flux dissipates.

Hey, my explanation make as much sense as yours...

Re:Thread bug?

[pavera]

wrong, this very well could be what is happening. kmail (the KDE mail app) has a very similar bug with pop email. If your hard drive gets full while the "fetcher" thread is downloading mail, there is no way for this thread to notify the parent process, which then happily issues the delete command to the POP server once the "fetcher" returns... and bamo! No email downloaded (cause the disk is full) and the email is deleted from the server... all gone to the bit bucket. The only fix to this problem is to "de-multithread" the application. Which is why Kmail still has this problem (it was reported 3 years ago, and I found the bug 2 years ago, but I don't have time to re-write kmail to not use the fetcher thread).

It could very easily be that the thread that is actually doing the move has no way to notify the parent that the copy failed, that thread fails out, but the parent thread happily deletes the local copy cause it doesn't know that the copy failed.

Re:Thread bug?

[philipgar]

wrong, this very well could be what is happening. kmail (the KDE mail app) has a very similar bug with pop email. If your hard drive gets full while the "fetcher" thread is downloading mail, there is no way for this thread to notify the parent process, which then happily issues the delete command to the POP server once the "fetcher" returns... and bamo! No email downloaded (cause the disk is full) and the email is deleted from the server... all gone to the bit bucket. The only fix to this problem is to "de-multithread" the application. Which is why Kmail still has this problem (it was reported 3 years ago, and I found the bug 2 years ago, but I don't have time to re-write kmail to not use the fetcher thread).

If this is your fix for the problem (removing threading) you really should not EVER touch multithreaded code. Hell, you probably shouldn't be trusted with any code more advanced than javascript. There are many ways to share data between threads in a multithreaded shared-memory machine. A fix could be as simple as having an array of status codes for each thread spawned. Another thread in the system is likely spinning in a loop polling the other threads to see if operations have completed. If the status code is valid (obviously access to the status code array is protected by a lock or some similar technique) the polling thread can go ahead and tell another thread to delete the data. Of course this requires that the status code is initially invalid, is never written to valid on a termination of the thread, and serialization of accesses to it. Also there should be memory ordering instructions around it (they're implicit on x86 when using atomic primitives, so locking handles this case).

Of course, this particular problem is unrelated to multithreading, and actually occurred in prior versions of OSX according to many comments. This makes sense, as I don't know why anyone would ever want to move files between volumes like this. I regularly copy data around, but almost never want to move it.

Phil

Re:Thread bug?

[Anonymous Coward]

Are you serious? I hope you don't code for a living (or even as a hobby). This is not a troll; I am looking out for the welfare of everyone.

Re:Thread bug?

[merdaccia]

Assuming that a child thread is created to perform the move, why would the parent thread need to be informed at all? The child thread would be responsible for the move in its entirety, i.e. perform the copy, delete, notify, and handle any exceptions.

If this bug was in Windows...

[Anonymous Coward]

Terrible bug. Entirely fixable I'm sure, but what about those who lost all their files?

As a user unlucky enough to run Windows you'll have to 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 what you need to do is be mindful every time you want to move a file anywhere.

Sucks to be a Windows user - I'm sure MS will have this fixed pretty quick but it doesn't help those who've lost hugely important files.

Finder Has A 'Move' Now?

[GaryPatterson]

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"

[MutantEnemy]

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.

Re:"haha"

[GaryPatterson]

Don't forget "lol" and "yay."

Only complete bastards would be happy that someone, somewhere lost important data. I'd like to see more transparency on the tagging mechanism, such as who voted for which tags.

Re:"haha"

[Joe U]

Only complete bastards would be happy that someone, somewhere lost important data.

It's a Mac, kinda like saying your 'speak and spell' lost data.

Re:"haha"

[gsking1]

In case you are serious about this question - I believe it is a reference to the Simpsons. A quick google found this...http://www.allposters.com/-sp/Nelson-Posters_i424903_.htm

Re:"haha"

[MutantEnemy]

Ah, Nelson. I hadn't realised that.

Re:"haha"

[GaryPatterson]

Fair enough. Like if Windows lost data, it'd be like saying "My gaming console lost data." Or if Linux lost data, it'd be like saying "My server lost data."

Actually that last one could bite.

Re:"haha"

[Yosho]

It's called schadenfreude. People outside the group like to make themselves feel better by laughing at the misfortunes of people inside the group.

Re:"haha"

[Anonymous Coward]

Or if Linux lost data, it'd be like saying "My unlicensed version of Unix lost data."

Re:"haha"

[NewbieProgrammerMan]

Does it count as schadenfreude if you're laughing at your own coding misfortunes? I've worked with people that were able to laugh at their own mistakes...generally they were easier to get along with than those that got defensive or denied there was a problem. :P

Re:"haha"

[Anonymous Coward]

A tour of a space facility in the US apparently prompted Prince Philip to ask how astronauts deal with "natural functions" in space. So how exactly do they go to the toilet (or should that be the loo)?

It's all to do with air flow. On earth, in the West at least, your standard toilet is a water-flush affair, that takes waste and washes it down a pipe.

THE ANSWER
Space toilet
Space toilets use air flow as water flushes have drawbacks in zero gravity
Adult nappies are used on space walks and during take-off and landing
The lack of gravity on the shuttle and the space station mean a water-flush system is not an option. You don't need a particularly vivid imagination to see the potential problems.

Instead, on the shuttle, urine and faeces are carried away by rapid flow of air.

The unisex toilet resembles a conventional loo, but with straps over the feet and bars over the thighs to make sure that the astronauts don't drift off mid-go. The seat is designed so the astronaut's bottom can be perfectly flush to make a good seal.

The good news for fans of convenience is that, on the shuttle at least, urinating standing up is possible. A funnel-on-a-hose contraption is included so that astronauts - both male and female - can urinate standing up. Or sitting down if they prefer. They just attach it to the toilet using a pivoting bracket.

I would wait for 10 hours and then once back inside get someone to help me off with the suit and rush to the bathroom
British astronaut Piers Sellers to Prince Philip
The system separates solid and liquid waste. Solids are compressed and remain on-board to be unloaded after landing. Liquids are released into space. Nasa hopes one day to recycle waste productively.

Researchers at the University of Guelph in Canada have said such recycling will be key to tackling any future mission to Mars in order to feed the astronauts.

The air used in the space shuttle's toilet system has to be filtered to get rid of the smell and bacteria before it is returned to the living area.

Incinerated waste

On the International Space Station, the fundamental principle is similar. The fan-powered air-flow toilet system stores waste. Urine is sucked up and stored in 20 litre containers which are dumped into the Progress resupply craft. The ship is later ejected into the atmosphere, where it burns up.

WHO, WHAT, WHY?
QM
A regular feature in the BBC News Magazine - aiming to answer some of the questions behind the headlines
For solid waste, a plastic bag covered in holes is placed inside the toilet. Air is sucked through the holes so everything ends up in the bag. The elasticised top closes and the bag is pushed into a metal container. A new bag is popped in for the next visitor. Again the waste heads off to Progress.

Space toilets have come a long way. In the book The Right Stuff and its film adaptation, an astronaut on an early mission feels the need to urinate during a massively delayed take-off. With no facilities provided - and no adult nappies, as used today during take-off and landing - he is eventually allowed to urinate in his suit, causing his sensors to go haywire.

And Prince Philip is among good company in wondering how astronauts attend to their bodily functions.

A spokesman for Nasa confirms it is a question much asked by children and journalists alike.

Re:"haha"

[I'm Don Giovanni]

Slashdotters aren't exactly the most mature people in the world.

Re:"haha"

[zanderredux]

/. Tagging System Impossible To Figure Out meta, bug, mystery, haha ... there, happy now? :)

Re:"haha"

[yabos]

I think it's because the trolls are happy that Apple has a flaw found in its code. Then you get the usual trolls about "I thought MACS just worked lolz".

Your plurals are weak, old man!

[Anonymous Coward]

s/is/are;s/it/they/

~ Obi-Wan "Gramma Nazi" Kenobi

Re:Problems

[Anonymous Coward]

You can say that again, but good luck trying to have a reasonable conversation with the Mac fanatics! Myself, I've been sitting here at my freelance gig in front of a Mac (a Imac w/4 Gigs of RAM) for about 20 minutes now while it attempts to copy a 17 Meg file from one folder on the hard drive to another folder. 20 minutes. At home, on my Pentium Pro 200 running Linux 2.4, which by all standards should be a lot slower than this Mac, the same operation would take about 2 minutes. If that.

In addition, during this file transfer, Itunes will not work. And everything else has ground to a halt. Even BBEdit Lite is straining to keep up as I type this.

I won't bore you with the laundry list of other problems that I've encountered while working on various Macs, but suffice it to say there have been many, not the least of which is I've never seen a Mac that has run faster than its Wintel counterpart, despite the Macs' faster chip architecture. My 486/66 with 8 megs of ram runs faster than this 2.4 GHz machine at times. From a productivity standpoint, I don't get how people can claim that the Macintosh is a superior machine.

Mac addicts, mod me down if you like, but wouldn't it be better instead to post some intelligent reasons why anyone would choose to use a Mac over other faster, cheaper, (not to mention more stable) systems?

Re:Haha

[CtrlShiftEsc]

Er, haven't your read, the same problem occurs under Tiger too...

10.5.0 has only been out for a week and all I've seen so far are people bitching about 10.5.0's ultra lean firewall which has actually regressed from 10.4.10; the Java incompatibilities; the Trojan, dressed as a codec specially for the Mac and now fundemental problems copying from one volume to another external volume. Though it pains me to say it, it's a big software project which only gets bigger at every release and things will never be perfect from day one. Even Apple make mistakes. Long gone are the days when testing was everything. Face it, YOU are the test and hopefully, it might be fixed in a point release if enough people are vocal about it.

The problem for Apple is that if they manage to gain new customers who purchase Leopard, it'll be harder to hide behind some of Microsoft's recent own goals in Windows Vista when they have some whoppers of their own to deal with. That core, evangelistic following of everything 'i' will have a smaller voice against the swell of must-have junkies that might be tempted to switch because they already own an IPod or IPhone but cry foul when they see no real difference with their Windows experience. Apple sets itself up with such lofty values and ideals and at a measureable premium, no wonder people are upset with even the little things.

Not default behavior

[Have Blue]

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.

Re:Not default behavior

[cbhacking]

Quick question: In Windows and KDE, you can Cut or Copy a file (or folder) using Control-X/C (or right-clicking) and then Paste it somewhere else. If you used Cut, the old file/folder location doesn't get removed until the paste completes successfully. Does this work on OS X? Most of the *work* I don on OS X is repair-related, which usually means I'm using a terminal, so I can't remember if this feature works like I would expect... but there's a reasonable chance I would try it without thinking at some point and potentially screw something up.

Undoing a mod here, but I'd be very interested to know.

Re:Not default behavior

[Have Blue]

In OS X you can only ctrl-c a file, there is no way to have it automatically remove the original when you paste.

Aye, there's the rub

[ackthpt]

Knowing it exists means you can also work around it

That's the rub -- not knowing about it until after you've lost irreplacable files.

Reminds me of this old poster I had on the wall with Moses looking down at a broken tablet, while thundering out of the cloud above him were these words: XI Thou Shalt Make Backups

AFAIK, this has always been an issue with Macs

[toadlife]

Hunter Kressel has been warning people about this for years now.

Re:AFAIK, this has always been an issue with Macs

[Anonymous Coward]

flamebait?

Pftt!

You idiot! You own a Macintosh! Your sense of humor is fucking gone!

Proof At Last

[Anonymous Coward]

This story proves that BSD is dying along with linsux.

There fixed it for you.

two questions

[cyfer2000]

1, how big is the impact of this bug? As far as I know, people barely do inter-volume move.

2, does the time machine thing bring the disappeared directory back?

Re:two questions

[zxsqkty]

Whenever I move data to a network drive / partition I always verify that the data was successfully copied before I delete the original, regardless of the OS I'm using. I've never been bitten by this bug.

It should be noted that cut / paste doesn't exist in OSX (the menu option exists but is 'greyed out'), and 'copy' is the default option if you drag a file to a network drive, but you can always use the command line 'mv' to move a file. I guess the only people who will witness this bug will be those that use the command line, and again I'd guess that they would be in the minority as the Mac OS is primarily a 'drag and drop' interface. I know that hitting a certain combination of modifier keys can invoke a move operation, but it's certainly not the default.

Nevertheless, it's still a bug...

Data deletion in Mac OS X

[Neo-Rio-101]

The other quirk that I really hate with Mac OS X, is that if you drop a folder with some data in it onto another folder of the same name in another directory with it's own data, all the data in directory you copy onto gets DELETED without so much of a warning.

I know this is a UNIX thing, but even Windows isn't that mean.

Re:Data deletion in Mac OS X

[Anonymous Coward]

Bollox is it a UNIX thing. UNIX doesn't do that, it will tell you the directory already exists. It's an apple fuckup. Just admit it won't you?

Re:Data deletion in Mac OS X

[w3woody]

That behavior is by design and has been the way Apple handles directory overwrites since 1985.

Re:Data deletion in Mac OS X

[GaryPatterson]

No, when I drop my test folder into the folder containing my second test folder, I get a warning about replacing a folder and I know that's been there since at least System 6 (my first Mac) and probably from the 1984 Mac. I tried dropping my test folder onto the second test folder directly, and it just became a sub-folder as expected, with all files intact in both levels.

You may not have given specific enough instructions though - can you give a step-by-step process to this bug? Or is it just not true?

Re:Data deletion in Mac OS X

[ncryptd]

I'm sorry, but you're flat out wrong. If you drop a new folder into a directory that already contains a folder with that name, you will be asked if you would like to replace the existing folder. In fact, the exact text of this dialog is:

An older item named "foo" already exists in this location. Do you want to replace it with the newer one you are moving?

There are two buttons: "Stop" and "Replace".

Re:Proof At Last

[Anonymous Coward]

"This story proves that BSD is dying..."

No, in this case it's just the onset of a computer version of Alzheimer's disease.

Bad finder, bad, bad finder...

[flyingfsck]

In my own limited experience, the Finder is the single worst feature of the Mac. Its interface is really bad and losing data is just another manifestation of a rotten design.

Not just 10.5

[rir]

This has been standard Mac OS operation for a long time. I know for sure that the same happens under OSX 10.4, and as I recall, older versions of the Mac OS (7/8/9) all did the same thing. Granted this is a stupid way of implementing file moving, the alarmist headline is a little unnecessary.

Re:Not just 10.5

[zxsqkty]

Granted this is a stupid way of implementing file moving, the alarmist headline is a little unnecessary.

But accurate.

Re:Not just 10.5

[SEE]

Hmm, so a move coded such that it doesn't actually verify the copy before the delete is standard for MacOS?

I've heard of a phrase for this sort of thing -- "defective by design".

File The Bug!!

[EccentricAnomaly]

Go Here: http://developer.apple.com/bugreporter/ And File a bug. And They'll fix it.

Re:SORRY!

[Anonymous Coward]

Someone wanna clue me in on what I'm missing, here?

Did anyone actually read the article?

[Anonymous Coward]

The blog post sure appears to be full of crap. I especially love the "pseudocode" that the move function "probably" looks like. The detail he has in the post is totally inadequate to implicate the OS itself.

people actually use the finder?

[zojas]

that's bizarre. I love OS X, but I have no use whatsoever for the finder. it's not like it's actually a good file manager or anything. seriously, if the finder just disappeared one day it would be a long time before I noticed.

Re:people actually use the finder?

[arlanTLDR]

What do you use instead?

Re:people actually use the finder?

[808140]

Terminal, obviously. Who doesn't?

Re:people actually use the finder?

[chefmonkey]

I get by with almost exclusively Quicksilver and Terminal. Finder has too many limitations to be all that useful.

In fact, it's almost as bad as Nautilus. ;-)

Re:people actually use the finder?

[zojas]

I use terminal.app and quicksilver

Re:people actually use the finder?

[Cro Magnon]

Who doesn't?

99% of Mac users. But I agree that all GUI file managers suck, and Finder sucks, even compared to other GUIs.

Re:people actually use the finder?

[808140]

It was sort of an ironic joke. Note that I am not the OP.

That's silly? You're silly.

[Nirvelli]

There's absolutely no reason that a modern "move" command shouldn't already be implementing the exact process you've just described, no matter where it is moving to.

Re:That's silly? You're silly.

[networkBoy]

Of course you are right. Except in this case it isn't.
I'm with all the paranoid ones here. I have a perl script I use often enough: FTP files, ask server to compute MD5, (and SHA1 if $PARANOIA==1), perl does the same at my end, compares if the hash(s) are correct the copy is deemed successful.
-nB

Re:That's silly? You're silly.

[TheUser0x58]

Well... not an intra-filesystem move, which involves no real data transfer, just moving the inode pointer to another place...

Re:That's silly? You're silly.

[Anonymous Coward]

Of course you are right. Except in this case it isn't.
I'm with all the paranoid ones here. I have a perl script I use often enough: FTP files, ask server to compute MD5, (and SHA1 if $PARANOIA==1), perl does the same at my end, compares if the hash(s) are correct the copy is deemed successful.
-nB So... why not just use rsync? Under OS X you can mount ftp as a drive, and you can do that under Linux with FUSE as well. So, why reinvent the wheel?

Mod Parent Up!

[GaryPatterson]

+5 logical!

Re:Mod Parent Up!

[Lunzo]

It's not logical at all. Why should moving one folder delete an existing one?

As for the warnings etc, how many users actually read those warning pop-ups? And if they do read them do you reckon they'd understand exactly what was meant?

Mac's are usually pretty good for usability. I'm surprised they'd make such glaring errors, such as not protecting a User's work, not letting them undo, and having strange behaviour which is difficult to learn on the basic file-system interface, which in theory any user should be able to figure out how to operate on the first go.

See: http://www.asktog.com/basics/firstPrinciples.html for more info on usability.

Re:Mod Parent Up!

[GaryPatterson]

As for the warnings etc, how many users actually read those warning pop-ups? And if they do read them do you reckon they'd understand exactly what was meant?

"An older item named "Foo" already exists in this location. Do you want to replace it with the newer one you are moving?"
Stop | Replace

So you think people have a hard time with that? You need to mix with more intelligent people!

And yes, I do think it's logical. Why shouldn't a folder replace another of the same name? It's all UI decisions, and so long as they're consistent, they're logical.

Re:Mod Parent Up!

[tftp]

This does not match the folder / filing cabinet metaphor. When a secretary receives a folder "Jim" with new Jim's papers she will not toss the old folder that is also called "Jim". I seriously doubt that we even have a real life situation when an old folder is trashed upon arrival of a new one. I can definitely understand now why Macs are not that popular. Destruction of data is not a good selling point, even if it appears logical. It should do the right thing, not necessarily the logical thing, especially because people are not always logical (they are not robots.) People make mistakes, and the computer should account for that instead of rudely saying "Well, you should have known, it's logical after all."

Re:Mod Parent Up!

[aftk2]

I think you're approaching the concept of "Folders" and "Files" within them from a more advanced position than the (typical? probably not..."target" maybe?) Mac user: Folders are not "collections of files and folders within them"; Folders are things. Like physical things. If I take a folder out of my filing cabinet and replace it with a folder from a different filing cabinet, the contents of the entire first folder are gone. Folders are things. They are not the sum of their parts.

(Like a previous poster said, this is definitely a behavior of the classic Mac, if I remember correctly, as its notion of Finder as a spatial file management tool.)

If I replace one "thing" with another "thing", the first "thing" is gone. That's logical. You may not agree with it, you may actually find it inconvenient, and, if you don't take the time to learn it or gloss over the warnings the system provides you, it might actually make your life difficult.

Re:Mod Parent Up!

[GaryPatterson]

I've always been a bit disturbed about the Finder's 'instant delete' actions, where files replaced in this manner don't end up in the trash bin but are just removed in an unrecoverable manner.

I see your filing cabinet metaphor, but having never done filing I wasn't familiar with this concept. I think the behaviour in the Finder is logical, but destructive. It should be recoverable, but it not. I don't think anything says "you should have known" but I see where you're coming from.

Back to School... Ole school

[starglider29a]

Obviously this person never copied anything to a floppy disk, then deleted without checking the disk. I used copy /v because MS was smart enough to compare the source and... ummm... destination... HEY WAIT A MINUTE!!!

[http://support.microsoft.com/kb/126457] When you use the VERIFY ON command, or the /V switch with the COPY or XCOPY command, the MS-DOS file system uses the block device driver command code function 09H, Write with Verify. This verification process consists of confirming that the data just written can be read (for example, that the data was not written to a bad sector on the disk). No comparison of the source and destination data occurs. To compare the source and destination files, use the MS-DOS FC (file compare) command after you use the COPY or XCOPY command. Ain't no school like ole school, baby.

Re:Back to School... Ole school

[SEE]

The authors of a move function should have enough sense to performs a copy-verify-delete, instead of just a copy-delete. I mean, the entire point of automating the task with a single "move" function would be to automate doing the right thing, not making it incredibly easy to automatically do the wrong thing.

***IMPORTANT MESSAGE FOLLOWS***

[Anonymous Coward]

1. Establish a backup procedure, preferably automated, on the day of install.
   
2. Perform your first backup on the day of install.
   
3. Ensure your backups happen as regularly as you can manage.
   
4. Test your backups regularly to ensure your backup method works.
   

Is that clear? If you don't have a backup procedure in place, stop right now, whatever you are doing and establish one.

If you have not followed this advice and experience data loss, it is your responsibility and your fault.

STICK THA APPLE WAY UP YOUR ASS!

[Anonymous Coward]

macs are for HOMOs

This may not be a bug in Leopard

[ChrisA90278]

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.

Re:This may not be a bug in Leopard

[El_Oscuro]

We lots of databases deployed on crappy wintel servers in remote locations. Prior to deploying any server, we lose the write cache. The group that handled deployments before us did not, and sure enough:

1. Server gets to about 3 years old.
2. Cache battery goes dead.
3. Power loss. Those committed transactions that were "written" to the redo logs on disk are gone.
4. Database fubar. Got backups?

Friends don't let friends have write cache turned on

Re:This may not be a bug in Leopard

[Cantus]

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.

I had this happening to me with WinXP aswell

[Lisandro]

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

Why doesn't move act like copy?

[antdude]

Why doesn't move act like copy and delete? Why must it delete right away during the moving?

Re:Why doesn't move act like copy?

[zxsqkty]

Perhaps because it's 'move', not 'copy then delete'?

Re:Why doesn't move act like copy?

[Ash-Fox]

Because it's badly implemented on OS X.

Macs are made for human beings

[rpp3po]

Only geeks would think that this is a bug!
It's always the human/machine-interface unit at Apple, who has the last word. By questioning their massive testing fleet of 'ordinary guys' they found out that 85% of their potential customers think of files as digital sausages (which can be sent through a series of tubes: the internet).
So Apple has implemented this feature just like a normal person(tm) would think. When moving he puts his file (the virtual sausage) into a tube, which is going to deliver it to another disk. When the tube is removed from the target before it can squeetze out the complete sausage, only a chunk of it is going be on the target disk - the rest cut off and stuck in the tube. So if you find posts like "How can I get the rest of my file out of the tube" you know what they are trying to express.

Or [possibly], go fix it.

[GodWasAnAlien]

You could possibly find and fix it yourself (and submit the fix).

http://www.opensource.apple.com/darwinsource/10.5/

Re:Or [possibly], go fix it.

[tftp]

Apple charges good money for Leopard, so let them fix it.

Re:Or [possibly], go fix it.

[andreyw]

Finder, and any GUI parts of OS X in general, are not part of Darwin.

Re:Or [possibly], go fix it.

[MochaMan]

And while we're at it, stop contributing to Linux and the GNU userland! Red Hat charges good money for that - let them fix it!

Re:Or [possibly], go fix it.

[Anonymous Coward]

well, yeah, if you paid Red Hat good money for Linux then they should be fixing any bugs you encoutner. That's kind of the idea of paying for stuff. But you can get Linux for free from other people. You can't get OS X for free from other people (legally). So the situations are totally different.

mv?

[fishbowl]

Does it fail in the same way with mv? And if so, is this maybe an expression of some BSD bug?

Re:mv?

[Anonymous Coward]

No, it doesn't, and although it would fix this issue, I'd be very worried if Finder actually called command-line utilities to perform things like this, as it's not generally good design...

Note that there is no Unix system call for moving hierarchies of directories (so it couldn't be a BSD bug unless it was a bug in the mv command-line tool itself), only a rename system call that works on the same device. What mv actually does is call cp -R and then (if successful) rm -r. What Finder implements works the same - scans the directory hierarchy, copies it and deletes - but apparently doesn't always (ever?) detect and abort if an error occurred during copy.

*gasp*

[spaxxor]

oh no apple has a flaw, the earth is gonna end

Re:Problems

[Space cowboy]

No need to mod you down. You're just wrong.

simon% dd if=/dev/zero of=test bs=1m count=17
17+0 records in
17+0 records out
17825792 bytes transferred in 0.297437 secs (59931329 bytes/sec)
 
simon% ls -l test
-rw-r--r-- 1 simon 501 17825792 Nov 5 18:32 test
 
simon% /usr/bin/time cp test ~/Desktop
        0.44 real 0.00 user 0.03 sys
 
simon% ls -l ~/Desktop/test
-rw-r--r-- 1 simon 501 17825792 Nov 5 18:33 /Volumes/Users/Users/simon/Desktop/test
 
  simon% uname -a
Darwin mac 9.0.0 Darwin Kernel Version 9.0.0: Tue Oct 9 21:35:55 PDT 2007; root:xnu-1228~1/RELEASE_I386 i386

... I suspect you have a hardware problem if it's really taking that long to copy files. The above 0.44 secs (wall-clock time) is on a standard internal SATA disk. No RAID or anything special.

Simon.

I notice the example REQUIRED WINDOWS

[wardk]

another lesson to be learned, don't disconnect drives while doing destructive commands.

try copy if you desire un-mounting mid copy.

god knows what OS X will do if you trying moving files while unplugging the computer.

hopefully slashdot will save a headline for that one

Re:Macs suck! not only they lose data..

[rpp3po]

but they usually take at least 20 minutes to copy a 17 meg file which at home, on my Pentium Pro 200 running NT 4, which by all standards should be a lot slower than this Mac, the same operation would take about 2 minutes. If that. I won't bore you with the laundry list of other problems that I've encountered while working on various Macs, but suffice it to say there have been many, not the least of which is I've never seen a Mac that has run faster than its Wintel counterpart, despite the Macs' faster chip architecture. My 486/66 with 8 megs of ram runs faster than this 300 mhz machine at times. LMFAO! Where is this guy writing from??
Sounds like he's living in a cave and using an old bicycle to deliver the energy for his server park. ;)

Shift+drag

[SanityInAnarchy]

This has been common on all OSes for awhile now -- not sure how it maps to Apple's "command" vs "control" buttons, but here:

ctrl+drag: copy
shift+drag: move
right-click+drag: pop-up menu with a choice between the two, or maybe more

(On OS X, it's been awhile, but I'll guess that command+drag is copy, and ctrl+drag is pop-up.)

Similarly:

select, press 'del' key: (usually) prompt for move to trash
select, shift+del: delete immediately, or prompt to delete -- permanent, no trash

Re:Shift+drag

[warrigal]

From Help:

To move files to a different location on the same disk, drag the icons to the new folder.
To move files to a different disk, hold down the Command key while you drag the icons.
To copy files to a different disk, drag the icons to the disk.
To copy files to a different location on the same disk, press the Option key while you drag the icons.
To open a folder while dragging an icon, hold the icon over the folder for a moment.(Springloaded folders)
To make copies of files within the same folder, select them and choose Edit > Duplicate. (or Cmd-D)
To delete, select and Cmd-Delete. To empty Trash, Option-Cmd-Delete.

How not to demonstrate this

[g-san]

/me clicks link to read story.

"Error 500 - Internal server error

An internal server error has occured!
Please try again later."

Webmaster needs to be reminded not to demonstrate this bug to people on his production server.

Microsoftisking!SteveBallmerisemperorVistaRules!

[Anonymous Coward]

You heard me!! This never happens to Microsoft products! Never! Bugs don't exist! Patches are our friends! Our Data is secure on NTFS. Steve Ballmer knows what he's talking about! Boycott Apple products and Steve jobs. Make the switch to MS! You'll regret every moment you don't do it and after you'll feel the same on MS!!! So make the switch to Linux/Unix! You just won't be able to play games or get devices to work right! So make the switch to Plan 9! You'll regret every moment you try to understand and use such a stupid operating system. In fact the smartest thing you can do is uninstall it. You're saved data? Well, there was none to begin with.

Not a bug...

[master5o1]

Apple just wants you to use the Time Machine to look for it ;)

Temporal problem

[Roger W Moore]

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:Macs suck! not only they lose data..

[Billly Gates]

Very old troll posting.

Similiar to the FreeBSD IS DIEING netcraft comfirms it... troll posts that are cut and pasted.

Ignore him and moderators do your job.

Re:Problems

[primalamn]

I swear I saw a post almost exactly like this on the Craigslist Apple forum one day about 8 months ago, this one has been slightly edited, but pretty much the same thing. Almost like a copy...

And I agree with the other reply, it really sounds like a hardware issue or possibly a corrupted file is in the batch you are copying. A 17MB copy or duplication on the same drive on my 1.67 PowerBook G4 takes about 2 secs. Maybe try the copy one at a time and see if you can ID any corruption.

Or, boot from the install/restore disc that came with it: insert disc, File>restart..., then hold the 'option' key down when you hear the chime, wait a min, select the hardware test button and run the tests.

See what happens.

Seriously?

[seandiggity]

I am absolutely amazed at the comments that seem to be proposing that Time Machine is a reasonable solution for this. As if a backup feature cancels out a bug that makes files go *poof*. If Ubuntu did this (or any large FOSS distro), they wouldn't be able to live it down. And if Microsoft did it, well...it'd be another Monday, I guess.

That's missing the point...

[megaduck]

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:That's missing the point...

[Anonymous Coward]

Seriously? GP is missing the point because Windows' backup capabilities don't have a clever name and spacy animations? This is the same Slashdot whose users repeatedly criticize Vista for being too much about eye candy. Here's a perfect example where Vista is fundamentally better and you bitch it isn't pretty enough.

Re:That's missing the point...

[Anonymous Coward]

Seriously? GP is missing the point because Windows' backup capabilities don't have a clever name and spacy animations? This is the same Slashdot whose users repeatedly criticize Vista for being too much about eye candy. Here's a perfect example where Vista is fundamentally better and you bitch it isn't pretty enough.

Grandma can use Time Machine easier. It's way simpler. Quite intuitive IMHO. Vista's version certainly works and is easy for someone who is computer savvy, but Apple just made restoring files as easy as it can get.

Re:That's missing the point...

[value_added]

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.

Not to sound overly critical, but a "feature list" doesn't, by definition, mean that any of those features are useful. It's the implementation that's the key, and as for the features you've listed, the implementation leaves much to be desired. Let's take the more well-known features:

ACLS? Useful in certain circumstances, I'd agree, but otherwise perverse. Hell, I'd bet the average user (or IT admin) isn't aware of, for example, the simple concept of file ownership, let alone what the default ownerships and perms are on standard (cough) system directories. Or on any of set of registry keys. Windows explorer hides files extensions, so it's unsurprising that it doesn't (can't?) present ACLs (with/or without the extra DOS attributes) when looking at a directory listing, so every user/admin can go on pretending everything is as it should be. Then, there's those nifty ad-hoc tools for managing everything ... I can't decide what's worse, right-clicking your way through a file system, or suffering while trying to make use of cmd.exe and the provided tools.

Alternate data streams a great feature? Name 3 people who know WTF they are, how they work, or a single example of their use.

Junctions? LOL. To the extent they work (and/or the extent to which the now-deceased Sysinternals slightly different implementation and corresponding tool) work or ever have worked, junctions are nothing more than an embarrassing and goofy implementation of symlinks. I'd give Microsoft another 2 OS releases to come up with something that's standard and useful. Put simply, Microsoft doesn't get symlinks. They want people to use shortcuts.

Yeah, NTFS has lots 'o features. And it doesn't crash and burn like everything the previous offerings from Redmond. I'd even go so far as to say it's generally problem-free and resilient, but there's that "implementation" thing again. Windows doesn't report sector read/write errors (no underlying terminal, and lack of logging are just two reasons) so you'd never know when a disk is going bad and read/write errors are occurring. Use ckdsk? Right. Try this as a homework assignment: figure out the differences between running chkdsk in cmd.exe window compared with using the context menu options for a given drive. Here's a hint: they're not the same, even for boot-time options. Do you know whether *any* sort of check is run at boot time? Didn't think so.

Oh, did I mention fragmentation? You'll need to pay for a utility to manage that problem, because what's offered by Microsoft (bought, actually) is as dumbed-down as it is featureless. Fragmentation not a problem? Create a new and roomy partition. Copy over a few large files. I guarantee each of them will have hundreds of fragments and be spread all over.

Even more surprisingly, it works pretty much as advertised.

Like I said, how would you know? ;-)

Re:That's missing the point...

[megaduck]

Alright, let's dance.

ACLS? Useful in certain circumstances, I'd agree, but otherwise perverse. If you've ever had to manage shared directories that cross corporate reporting structures, ACL is invaluable. Say that Susan in Accounting wants all of Marketing, Accounting, and Sales to have full access to an Excel spreadsheet, except for Bob. Bob is in marketing, but he's an intern and doesn't need to see that data. For a lot of sysadmins, situations like this happen all the time. UNIX permissions just don't hack it.

Alternate data streams a great feature? Name 3 people who know WTF they are, how they work, or a single example of their use. Alternate Data Streams allow HFS compatibility. There's still a shocking amount of Macintosh files out there that need to have their "resource fork" maintained, and NTFS permits you to host those files properly. Again, you may not care, but there's a lot of IT folks that do.

Junctions? LOL. To the extent they work (and/or the extent to which the now-deceased Sysinternals slightly different implementation and corresponding tool) work or ever have worked, junctions are nothing more than an embarrassing and goofy implementation of symlinks. LOL yourself. They're kind of funky, but you know what? They work. Reliably. Agreed, the lack of tools makes them largely unusable, but that's not NTFS's fault.

A lot of your "problems" are actually with the tools, or the kernel. You seem to be conflating NTFS (which is generally a pretty competent product) with all of the stuff that runs on it (which isn't). Do you want me to agree that it isn't leveraged properly? That was my whole point. NTFS is a great example of a diamond-in-the-rough, something good that's encased in crap.

Re:That's missing the point...

[TheNetAvenger]

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?


Why would you even be in the Backup and Restore Center?

Right click any file or folder and select 'Previous Versions' a timeline list of all the file versions are presented, INCLUDING any that are present on external/network backups.

From the timeline list dialog you can copy, restore, open, preview, open the folder from that time period on every version of the document or folder in the list.

I think MS made theirs a bit too simple, maybe if they would have created an application that had stobe lights and took 2 minutes to load to 'enter the time machine' people would think MS is also cool.

But instead they just make it intuitive, easy, and even available from dialog boxes of applications written 10 years ago.

Truly not trying to pick on you, but because it is such an elegant part of Vista, you like a lot of other people don't seem to realize it is even there.

Personally I prefer the MS interface 10x over Time Machine for use, especially since it is a clear timeline based list, and works from any shell object like dialog boxes, explorer folders, etc.

I will admit though the 'spacey' look of Time Machine is kind of cute, just not so functional when all I need to do is grab an earlier version of a document or folder I am working on.

For example: Right Click - Restore Previous Versions - Drag the version I want to my desktop.

(This is where I repeat, MS's marketing is insanely stupid. They should have been showing off features like this instead of the stupid Flip3D crap that even Vista users don't care about.)

Re:That's missing the point...

[TheNetAvenger]

Grandma can use Time Machine easier. It's way simpler. Quite intuitive IMHO. Vista's version certainly works and is easy for someone who is computer savvy, but Apple just made restoring files as easy as it can get.


Really? Opening Time Machine and scrolling through times/dates and windows is faster?

In Vista you right click on a file or folder - select Previous Versions and are given a timeline list of all the versions available.

I would bet if you saw the Vista feature, you would go, WTF, why didn't Apple just make it simple and work this easy.

For some reason people only notice the 'backup & restore center' in Vista, which is NOT what is being talked about here. Previous Versions in Vista is just a right click away in any folder or open/save box.

My personal choice would be to have the Vista version because it works easier and does more, and combine that with the Apple marketing team so everyone in the world is screaming to have it like a petulant child.

Re:That's missing the point...

[TheNetAvenger]

Ok, you need a nap after all that. :)

First you really should try or at least look at the technical aspects of Vista, most everything that you have a legitimate bitch about is no longer true.

Junctions? LOL. To the extent they work (and/or the extent to which the now-deceased Sysinternals slightly different implementation and corresponding tool) work or ever have worked, junctions are nothing more than an embarrassing and goofy implementation of symlinks. I'd give Microsoft another 2 OS releases to come up with something that's standard and useful. Put simply, Microsoft doesn't get symlinks. They want people to use shortcuts.


MS has supplied tools since Win2K. However in Vista not only are they available, but a key and critical part of the OS. To illustrate, many things that moved in Vista use them for compatibillity, like \Documents and Settings are now Junctions to \Users

Alternate data streams a great feature? Name 3 people who know WTF they are, how they work, or a single example of their use.

Other than every Mac user that shares or stores documents on a Windows in their house?

Windows doesn't report sector read/write errors (no underlying terminal, and lack of logging are just two reasons) so you'd never know when a disk is going bad and read/write errors are occurring.

Actually Vista does, and even alerts users of errors from HD errors or SMART codes.

Do you know whether *any* sort of check is run at boot time?
Um, not unless the volume is flagged. With XP the chance of an NTFS volume needed a chkdsk is pretty rare. NTFS is very good at protecting data and preventing even power off problems.

With Vista the need for a user to run chkdsk is virtually gone.

Why is Vista different? Well Vista first adds in an extended version of journaling. Then Vista has background HD reliability, in that when a write or read error occurs the OS notices this and runs internal checks on that area of the HD for problems. And even if the HD is increasing failing, it will relocate all the data around those blocks to safe areas and mark them bad.If this continues to get worse the OS does more than make a note in the journal it gives the user an alert.

Oh, did I mention fragmentation? You'll need to pay for a utility to manage that problem, because what's offered by Microsoft (bought, actually) is as dumbed-down as it is featureless. Fragmentation not a problem? Create a new and roomy partition. Copy over a few large files. I guarantee each of them will have hundreds of fragments and be spread all over.


You should go look up the 'decision' process NTFS uses when saving or copying files. It is a good urban myth that NTFS sucks, but actually it is one of the better FS implementations for keeping fragmenting down, and also one of the better systems for not allowing fragmenting to slow file access performance due ot the nature of the MFT.

There are a few FS that may fragment less, but not with the copy-on-write features of NTFS. This is why ZFS also tends to fragment more than the average generic FS. Some features have an inherent cost, and this is one of them, but worth the snapshot abilities NTFS provides.

Also the Vista defrag tools not only defrag properly but optimized file layout for performance (XP did too), but Vista's defrag also handles the MFT, registry, and other files that were locked in Win2K and XP.

Re:That's missing the point...

[essinger]

IMHO, the biggest problem with "Time Machine" is that Apple is advertising it as a backup solution, but tells you to leave it connected to your computer. Grandma thinks she has a legit backup. Grandma is wrong. Archiving old version of files is great, but you still need a backup seperated from your computer.

So much for the Lepard better than Vista arguments

[Anonymous Coward]

I thought the slow copy problem in Vista was horrible, but it is nothing compared to this horrendous bug in Leopard

Re:Problems

[Daengbo]

How can you have a 5-digit UID and still have never seen the 17MB troll? Did you buy your account on ebay? P200. How old do you think the troll is?

Re:Macs suck! not only they lose data..

[frdmfghtr]

LMFAO! Where is this guy writing from??
Sounds like he's living in a cave and using an old bicycle to deliver the energy for his server park. ;)

Didn't you see the sign when you came into the park? "Do Not Feed the Trolls!"

They are on a very strict diet of bullshit, you know.

FIX THE FUCKING FINDER

[argent]

The workaround for this is to not use Finder, basically.

Apple, fix the fucking finder. At the very least dig the fucking source code to the NeXT file manager out of the crypt and put it up under the APSL so we can take over for you with a file manager that isn't based on the rotting corpse of Classic Mac OS.

Finder is pretty much the last revenant shred of the grave-cloths of the old Mac. We know you're really really into it, but it's really really bloody horrid. Let it go to its rest, 'kay?

Couldn't replicate this bug

[TechnicolourSquirrel]

On OS X Tiger. I tried doing a move (command-drag) to an AppleShare IP volume I had mounted, and then pulling my ethernet jack in mid copy. Got the beachball of death. Could no longer eject my CD. The right side of my menu bar stopped responding to clicks. The Finder crashed and relaunched, leaving an orphaned Spotlight search window which forever hung there in an unusable state. Pretty much everything that could go wrong, did go wrong, short of a kernel panic, EXCEPT the original file was right there where I left it -- no data was lost. Perhaps in pre-Leopard versions of OS X, the Finder was just too flaky for anyone to get as far as discovering this bug? After all, if your Finder tends to crash and hang-requiring-a-force-quit whenever you pull a volume mid-copy (especially network volumes, which face it are the only place this is at all likely to happen accidentally) -- then it's not going to get as far as remembering to fuck you over in the way its buggy programming dictates. Leopard's Finder doesn't hang on network problems; therefore it is free to happily and incorrectly erase your data. If I *ever* used command-copy, I think I would prefer the old behaviour, but seeing as there is NO GOOD REASON to ever use this modifier key, I don't much care. Didn't anyone else have a moment of pause in contemplation of executing a volume-to-volume move, thinking, yeah ... yknow what? I just don't trust hard drives THAT much. I want to verify that the copy looks kosher before I pull the trigger on the delete. This is the way I've always felt about that function. This is not to excuse Apple for fucking it up -- I'm just saying that this bug is extremly, extremely obscure in my view, though quite potentially destructive. Oh and by the way, for those of you constantly complaining that copying a folder COMPLETELY replaces the contents of the one with the same name ... if you only knew, how much time I have spent over the years digging through unexpectedly 'merged' folders on Windows systems to separate out the intended wheat from the should-have-been-deleted chaff, you would realise that this is simply a matter of habit and of taste. There are way more instances when I want a folder to replace another completely, then to have them merged. When you know what your OS is going to do then there is no problem (and the Mac OS has NEVER wavered from its approach, and I'd like to remind you that drawing an analogy from the file behaviour, what happens with folders in the Mac OS is exactly what you would intuitively expect to happen had you not been trained on a conflicting system). If the Mac swiched to the Windows/LINUX way now, I would end up wasting a WHOLE lot of my time picking merged folders back apart. For the sake of something which, to me, makes no intuitive sense, anyway. YMMV.

Re:Couldn't replicate this bug

[argent]

The Finder crashed and relaunched, leaving an orphaned Spotlight search window which forever hung there in an unusable state.

If the finder crashed, then why would you expect your test to be replicating this failure mode?

Try killing the file sharing process on the other side instead of just killing the network connection.

Re:Couldn't replicate this bug

[TechnicolourSquirrel]

The Finder crashed and relaunched, leaving an orphaned Spotlight search window which forever hung there in an unusable state. If the finder crashed, then why would you expect your test to be replicating this failure mode? Try killing the file sharing process on the other side instead of just killing the network connection. Sure. But that's not the point that I was trying to make. What's more likely that, the remote filesharing process will go down, or that something will go wrong with the network connection along the way? The latter seems to me the far more likely situation -- which is why this bug has barely ever been remarked up by the rank-and-file Mac-using population -- precisely because the Finder rarely survives long enough to encounter it. The 'failure mode' itself would be in comparison an exceedingly rare event, is what I was trying to get across.

Re:Couldn't replicate this bug

[Anonymous Coward]

The point is a hard network disconnect causes driver responses and all sorts of other noise. Most network issues DON'T involve the plug being pulled, You can have plenty of network based issues without pulling the plug, killing the file sharing process on the remote machine is a good option for testing and process crashes are also far more common in enterprises than someone pulling the plug on the network.

Re:Couldn't replicate this bug

[TechnicolourSquirrel]

The point is a hard network disconnect causes driver responses and all sorts of other noise. Most network issues DON'T involve the plug being pulled, You can have plenty of network based issues without pulling the plug, killing the file sharing process on the remote machine is a good option for testing These are good points.

and process crashes are also far more common in enterprises than someone pulling the plug on the network. Can't agree with you there. You may have an extraordinary stable network connection, but there are a *whole lot* of people who don't. Where I live now until a few months ago the connection would go down (as in terminate, with effects exactly like pulling the plug) whenever the phone would ring. (I checked out the filter situation several times, they were fine.) And I have seen plenty of other people with wonky internet connections in their homes that go down (not slow down, GO down) at a moments notice, with exactly the same effect on the Tiger Finder as pulling the plug, if network shares are active. Filesharing processes going down on the server in mid-copy is in comparison something that I have almost never encountered. You're comparing process crashes versus lost connections *in enterprise* -- but you need to include the whole end-to-end in your assessment. Flaky connections happen to home users every day, and they *will* kill the Finder before it gets a chance to execute any buggy post-filemoving code -- at least they would before Leopard solved that problem and revealed another. Now that the Leopard Finder's network issues are fixed this bug is much more of a potential issue for the average user than it used to be -- at least the average users who know about command-copy.

Re:Couldn't replicate this bug

[argent]

What's more likely that, the remote filesharing process will go down, or that something will go wrong with the network connection along the way?

Depends on what actually happened, and what broke the Finder.

If the Finder broke because it blocked writing data to a hung socket, that's different than if the Finder broke because of an error handling bug when it wasn't expecting the condition reported when the connection was torn down.

In the former case, any failure on the server that closes the connection will likely still trigger the bug. And since Leopard Finder uses multithreading more aggressively it may avoid getting badly blocked on a hung thread.

In the latter case, there are likely to be other data loss scenarios lurking.

Either way, it's a real problem.

Finder's pretty long in the tooth. It needs a fresh rewrite, starting over from with the NeXT file manager and without the legacy Carbonized Classic code that came over from the OS 9 Finder.

You can do the same thing without Windows.

[argent]

You can pull a USB drive out.

You can kill smbd on another Mac.

You can pull your bloody network cable out.

don't disconnect drives while doing destructive commands.

It happens. You're right, this is only a problem when you're faced with an unexpected I/O error. The thing is, when that occurs, you're supposed to recover from it and NOT complete the copy-and-delete as if it hadn't.

Re:Problems

[dreddnott]

This troll has been going around the slashdots for near on ten years now.

http://www.kottke.org/98/11/my-mac-sucks

I believe this is the original version. You can see that with a little modification it becomes an easy trap for internoobs, producing much lulz.

Abble?

[Anonymous Coward]

I think there might pe a broplem with your keypoarq.

Obligatory Leopard flame...

[ComputerPhreak]

I don't want to start a holy war here, but what is the deal with you Leopard fanatics? I've been sitting here at my freelance gig in front of a fresh install of Leopard (on a iMac w/ 2 gigs of RAM) for about 20 minutes now while it attempts to copy a 17 Meg file from one folder on the hard drive to another network folder. 20 minutes. And it lost my files after my cat decided to pee on my Airport base station. At home, on my ancient Alienware Quad-Core running Vista, which by all standards should be a lot slower than this machine, the same operation would take about 2 minutes. If that. And not lose my data. In addition, during this file transfer, Finder will not work. And everything else has ground to a halt. Even iTunes is straining to keep up as I type this. I won't bore you with the laundry list of other problems that I've encountered while working on various file transfers, but suffice it to say there have been many, not the least of which is I've never seen a Leopard that has run faster than its Longhorn counterpart, despite the Leopards's faster leg architecture. My Vista box with 8 gigs of ram copies files without data loss better than this 4000 mhz machine at times. From a productivity standpoint, I don't get how people can claim that Leopard is a superior operating system. Leopard lovers, flame me if you'd like, but I'd rather hear some intelligent reasons why anyone would choose to use Leopard over other faster, cheaper, not-going-to-lose-my-files-during-a-transfer systems.

Or for short...

[istartedi]

Tard.

Alternative

[Jerry Smith]

I don't move them, I put them in the trash, thén move them to another partition. If something goes wrong, it's still there, if everything's going to plan, it's already in the trash. Stupid, but works for me. Sinds '96 :)

Bugs and Fanatics

[Anonymous Coward]

Well I don't believe that I am here to flame, although I am sure there will be others that say otherwise. I cannot for the life of me believe that there are Mac fanatics out there that are actually trying to defend Apple with a serious bug like this. If this bug actually is a real one then this is a serious problem. You have to be able to rely on your operating system to provide you with the most fundamental operations. Apple's developers are human, and humans make mistakes and have bugs in their code. I am certain that Apple will fix this bug quickly as well. I am just surprised how blind people can get when they get caught in the hype of a company that they believe can do no wrong. No company can do that. I can only imagine what these same people would say if Vista had the same bug. For me I use Linux (which also has plenty of bugs, but anyone can fix them).

Hey, thanks!

[Captain Tripps]

I've been using a Mac user since System 6, and never knew about the command-drag behavior. Of course now that I do know about it, I can't actually use it because of this bug. But, um, theoretically speaking it sure would be handy.

It doesn't sound like a bug

[Anonymous Coward]

As I said on tomkarpik.com:

I think what is occurring is an effect of write-back caching, which operating systems use to improve performance.

When you ask to write a file, the operating system (OS) stores the change in RAM, but delays actually writing to disk until later. The OS reports a successful write and lets you continue with your work, on the assumption that the disk-updates really will take place as expected. This enormously improves performance. It lets you continue your work which, in the case of a move across volumes, would be to remove the original file (this also will be reported as successful before actually being committed to disk.)

Without realising it, you caused the loss of data by interrupting access to the disk (or server.) You can probably specify a mount property or flag, probably called "synchronous", which will physically write to disk (or server) before permitting you to continue your work; it really will slow you down.

Worse Bug - Archive and Install Fails

[jordan314]

I had a horrible time installing Leopard. I tried to Archive and Install preserving network and user settings, and at the end I got a "OS X 10.5 Install Unsuccessful. Could not migrate previous user directory. Press here to reboot and try again." I rebooted and tried an upgrade instead, only to find that archive and install had only copied part of my home folder but already moved it, and upgrade deleted my old home folder. It did not save my documents folder or desktop in the previous system folder. I blog about it here: http://problemstosolve.com/os-x/leopard-archive-and-install-wipes-away-documents-unsolved/ Another problem I have about Apple's copying is how there are a number of errors that will make it fail in the middle of a large copy, and you have to start all over again. These include file names that are too long and permission/file in use errors. If I'm copying 48 GB and it fails halfway through, it just quits, and if I fix that file and start over, it may just fail again on another file. I've found rsync and ditto to work somewhat better, and the free GUI tool iBackup to be the best at doing complete copies and logging instead of quitting.

Whats the problem?

[bussdriver]

I've used macs for a long time and I rarely was stuck when non-recursively merging two folders:
Open folder A
Open folder B
Select all
Drag into folder A
Pick Replace

Recursive merging, thats what rsync, psync, pax, or ssync are for.

My expectations are such that I never was surprised by the folder replace option; same name files replace why wouldn't same name folders? Its consistent (plus I learned to read dialog boxes.) A non-recursive merge is manually possible in a few intuitive steps. A recursive merge that doesn't complicate the GUI for beginners I'd like to see. Now if you learned conventions from other systems I don't see how you can expect a 'beginner friendly' system to follow those conventions when their target user is not you.

Could easily happen in Linux...

[Creepy Crawler]

As long as a process can see the starting inode of a file, one can start to copy it. Once a program copies after inode 0, it can procced to the next linked inode. Easy enough.

While this process is copying, we can use the "rm" program which removes inode 0 from the superblock tables. inode 1 still links to 2 and on and on. rm just removes the start block.

I'm betting that Apple's finder does exactly this: cp /here /there || true && rm /here

Re:Could easily happen in Linux...

[gedhrel]

inodes are not blocks. What you've described doesn't sound much like the operation of e2fs.

Re:Could easily happen in Linux...

[Creepy Crawler]

Sorry, I was drunk and sleepy at that time I posted that.

I knew what I was talking about... well, sorta.

Already learned that lesson thanks

[dave562]

This reminds me of a lesson I learned A LONG time ago. Doing a move operation on important files is a BAD idea. In my case it involved Windows NT Workstation 4.0 and a Novell 3.12 server, but I'm sure the result was the same. Some files made it, some that hadn't been moved yet were still there... about twenty or so files out of a couple thousand were simply missing. The next couple of hours were spent archiving and recovering data from a backup tape. I don't think that you can really blame Apple for hardware failures. It's not like Macs come with Battery-Backed Write Cache enabled RAID arrays.

hee hee hee

[Anonymous Coward]

Your post is hilarious! You clicked OK without reading the dialog, then call the behavior "insane" because it doesn't behave like the Windows File Manager.

Hee hee hee hee hee hee...heh.

Re:hee hee hee

[Zebra_X]

Nah, just didn't work like every other OS I've used, e.g. Linux, BSD, Unix, Solaris, Windows.

Destructive by default is really a poor philosphy. This actually shows itself in other areas, such as the default iPod nuke when plugging an iPod into another computer.

sweeeet

[commodoresloat]

I'm installing KDE just so I can go into a K-hole.

Re:Problems

[S.Rowsby]

Reading that resulted in me just having the textual equivalent of someone calling my name and it not being for me. Yeah yeah, ot, first post, etc.

Problem is older than Leopard

[Absentminded-Artist]

I encountered this error last month. I lost 195gb of data.

I was moving an 8gb folder from my iBook to my external drive. The drive was connected to my iBook via firewire. I'm not sure what went wrong because I was hurrying but I noticed that the transfer wasn't working so I cancelled it. I tried it again and after a while it began moving 195gb of data, but I was only transferring a 8gb folder. I immediately hit cancel and 195gb on my DESTINATION drive disappeared.

I spent a week and a half using every tool known to Mac to get that data back, but it was gone. I believe these bugs are related, but unlike this one I was never able to recreate the other bug. I had always attributed it to user error because I was rushing or hard drive read/write errors. The drive was totaled after this. Bad blocks everywhere. Now I wonder if the bug caused the hard drive errors. It would be nice to have Apple to blame. I lost a big video project when that drive failed.

I realize we take our chances with ephemeral digital media, and I certainly backup all my personal data, but this project was enormous. I didn't have room to duplicate it on another drive. Sure hope all this attention gets the fire under Apple's butt to look into this problem and fix it.

Undo

[Hozza]

The Finder does have an Undo command. Work's fine over a networked drive too.

Pretty Big Tip But It's Worse

[Anonymous Coward]

That's a pretty big tip to the iceberg but in fact it's a lot worse.

1. All Cocoa file operations are written to fail if the destination exists. Think about it: there's no way you can overwrite any file (or complement any directory) with Apple's current API. If a Unix file doesn't have the 'w' bit set you get sent away; in Cocoa this situation can never occur. At all.

2. The sanity check code that any self-respecting file system normally has is totally absent in Apple's rewrite of NeXTSTEP. Both NSWorkspace and NSFileManager can do almost anything to corrupt a file system. Cyclical operations aren't caught and neither are no-brainers like trying to overwrite a directory with a file and so forth. These issues have been brought to the attention of Apple many times but are always summarily dismissed with 'works as designed'. Personal comment: if that's truly 'works as designed' it's got to be one of the crappiest designs ever.

3. Any number of third party applications such as file managers, editors, M$ Office apps, et al each have their own sanity check code to prevent file systems trying to overwrite themselves, overwrite directories with files, and so forth. None of this is integrated into the file system APIs where it should be.

4. At least earlier versions of Finder would fail on some cyclical operations out of pure dumb luck: trying to copy a directory onto itself would not result in a diagnostic that the user is round the bend but that 'the destination is currently in use by another process'. There is no other process - it was the Finder not knowing its right arm from its left.

5. GNUstep code is not written like this what I've seen. At multiple levels the GNUstep code is going through the same sanity checks all over again. It's redundant but it's also very careful. It's not only that Apple show no such care but that by all accounts this code used to be in NeXTSTEP/OpenStep but at some time after the NeXT/Apple merger was ripped out. Some of it perhaps migrated to Arno Goudrol's Finder; some of it may have been dropped.

A file system API provided by the OS vendor that does not protect itself is not much of an API. This is not only about user error through a file management tool: these APIs are exposed throughout the system and can be used by any application in the system; and the slightest error in any third party application can hose the HDD whilst the file system APIs stand back and refuse to comment.

Apple's first ever build of Safari contained a fatal flaw: using comparable APIs Safari somehow managed to hose the user home directory with a download - another case of a file overwriting a directory. Within hours people were aware of the issue and within hours Apple silently replaced 'build 48' with another 'build 48' and pretended nothing had happened. Smart users compared message digests and discovered that Apple had made a replacement without commenting. To this day Apple refuse to comment on the issue.

File management the Apple way is downright stupid: it's ripe with dangers not present in other more prevalent systems and the risk of massive destruction is always imminent. You have to wonder - especially in light of this latest disaster - what exactly they think they're doing. Cover Flow is not a lot of fun if there are no files left to browse.

This goes back a long way

[simong]

I'm sure I can remember seeing a similar situation under Solaris 2.5.1 many eons ago, and it's nothing new under SMB/Samba. Finder is still appalling with network drives - try mounting your iDisk on the Desktop, which is quite easy to do by mistake if you have a .mac account, and go and make a drink while the OS tries to come to terms with connecting to a WebDAV device several thousand miles away.

This is actually a problem in the way that BSD based Unixes handle files. In fact mv[8], which is still the underlying command here, is stateless, and sequentially writes to destination and deletes from source until the filehandle closes, so if *anything* interrupts the process, the state of the file will be incorrect in both source and destination, which I would guess (I haven't looked too deeply into Unix filesystems for a very long time) would affect the way in which it is reported to the GUI: you would end up with a chunk of data that is missing inode information at both ends but that is still on the disc, so the GUI just stops reporting it. I can definitely recall this happening in CDE/Motif in Solaris 2.5.1.

However, unless you're telling it otherwise like you are here, the default action for transferring data to any external drive is copy rather than move, which is *safe*. If you want verification, use rsync, which was invented partially because of these issues over SMB/Samba.
So in short, nothing new here. It's not an acceptable situation but it's an existing problem, and it's been found in Leopard because it's the latest version of the first genuine mass market Unix based OS.

Sometimes I wish I wasn't so sensible.

osx ?

[l3v1]

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.

Re:osx ?

[Ash-Fox]

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.

I have tested this and couldn't replicate your issue. The file being moved was still intact.

Re:osx ?

[essinger]

You might want to do thorough check of your disk. I have made this mistake many times in the past, and the original file is always intact. I think it is a problem, however, that the damaged destination file doesn't indicate that it is damaged. You might think, "oh, I must have done a copy." I've been burned by that a couple times.

Re:osx ?

[l3v1]

I've done that, no problems, and the files were really gone. I was pretty surprised, never seen anything like it. No probs though, I had the files on my portable drive, still, it was wierd. By damaged I meant that the first .avi was there on the media pc, it's size as a file was correct, but large chunks of it were missing and was unplayable. Anyway, I didn't want to make much fuss about it, just thought I'd mention since the general opinion regarding this bug in OSX here and in other forums seems to be fairly negative, but well, we all know that bugs happen, certain other OSes have taught us well :)

Re:osx ?

[wdolez00]

Windows does not remove the file you are transferring until the transfer is complete. If the transfer stalls, the file will still be in its original location. Plus if you are transferring multiple files at the same time it still does it on a file by file basis (transfer file 1, file 1 transfer complete, remove file 1 from the old location, transfer file 2, etc...).

Use Copy first!

[cycler]

First: This bug is inexcuseable......

But still.... if anyone is MOVING data then they should now that this can happen...

If you want to move a directory tree you ALWAYS _COPY_ the tree to the destination point.
AFTER it's finished you can check the directory size and number of files to ensure that everything
is copied. THEN you delete the original.
This is also faster then to move individuel files.

I've had Windows truncating MP3-files with coping aswell.... guess nothing is perfect...:)

Speaking of perfect, a big apologize for my bad english. I'm in a hurry and I feel this post isn't one of my
better ones regarding language...

/Cycler

All O/Ses have it wrong.

[master_p]

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.

Re:All O/Ses have it wrong.

[cbhacking]

First of all, files should never be deleted, they should only be hidden, unless the disk is full, of course. Great idea; you've just forgotten to give a name to those files left behind. How about Shadow Copies? Except, if you're going to store shadow copies anyhow, wouldn't it be great to checks if the files has been modified, and store shadow copy of the modifications? You could do it across the whole drive even, and call it Volume Shadow Copies!
(Okay, to be fair, Server 2003 and Vista won't actually store a VSC of a file if it was briefly created then destroyed; it needs to persist long enough for the shadow copy service to locate it and create the copy. Still, it works pretty damn well. Also, your suggestion, although it has merit, is missing one important detail: a way to TRULY delete the data if, for example, it's something sensitive and you really want it gone. Oh, and technically you could say that all filesystem (that I know of) do this anyway; that is, they don't actually delete the data off the disk, merely delete the inode from the allocation data. However, nothing is stopping the system from overwriting the exact spot the deleted file was on its next file create.)

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. Yeah, wouldn't it be awesome if it asked if you wanted to leave the old file, replace it with the new file, or rename the new file automatically? Hey, maybe it would even give you a thumbnail, tell you the files' sizes and modified dates (and which one is larger/newer at a glance) and provide big, clear buttons with multiple words on them explaining exactly what each does! Hey, it could even do that for folders too, right? Of course, it might get tedious to constantly approve overwrites, (or ignoring of copies that are already present, or whatever) so maybe it should have an option to remember your response for the rest of the operation...

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. See suggested improvement to the first idea. It's not CVS or anything by a long shot, but it's great if I accidentally overwrite a file, such as an image or copy of my resume, with an undesirable change that I can't undo.

I take it you haven't ever truly used Vista?

Re:All O/Ses have it wrong.

[master_p]

Yes, a capability to truly erase data would be welcomed, but only after a triple confirmation by the user.

I haven't used Vista because I don't need bloatware. I tried it, but it was ultimately slow on my machine, and very confusing, and the GUI sucks big time.

The pity for you is that you think Vista is a pioneering O/S because it has these features, whereas these features should exist in operating systems at least from 1990.

That is bizarre

[LanMan04]

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. That is totally bizarre, and I would *never* expect a file transfer to work that way. The new folder should replace the existing folder and all its contents. Talk about a way to get craaaazy mixed up.

Re:That is bizarre

[JunoonX]

Perhaps, but it works more or less like a merge, which I personally find better than overwriting a folder entirely. If I need to overwrite folders then I would rename the older folder, move new folder, essentially the same thing that OSX does. If I need to sync between the latest files between the two similar folder then use a sync job using Microsoft's SyncToy (this has been one of the best tools to come out of Microsoft, I'm even surprised it actually didn't get bloated with crapware yet). The above is expected behavior per me, perhaps because I have considered dragging and dropping two similar folders as merging rather than "overwrite" all content. But again its just what I expect on Windows, while my primary workstation, Ubuntu, works in an expected Debianish way that it should. I rarely use my Mac mini, so I wasn't aware of the behaviour this article describes. I likely would have flipped out had this happened to me.

Re:That is bizarre

[Yer Mom]

The reason it works this way on the Mac is because applications are simply folders ending in ".app". So, when you drag the new version of iDoStuff from the disk image into your Applications folder, you end up with a shiny new version rather than the new version with bits of the old one left over.

I wish there was a way of forcing it to merge (say by holding a key down while dragging) for when I'm not dragging apps, though...

Command line

[Legion303]

When I am booted into OSX(86), I don't use most of the GUI utils for simple operations. So everyone who uses

sudo tar cf - . |(cd /Volumes/newdir; tar xvf -) ...probably won't run into this bug.

This may not get read, but still

[analog_line]

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

I'm sure Win95 had the same bug

[gonzoxl5]

I vaguely remember, in the timeslieceocene era of Win95 encountering exactly the same bug, but wouldn't that mean ????

it couldn't be.......

Nooooooooooooooooooo!!!!!!!!!

Semantics

[ratboy666]

Remote File System semantics are HARD. Very hard.

It is not at all clear that Windows (CIFS or SMB) semantics are correct.

NFS is more so, but users tend to subvert the protocol (early "OK" returns) for performance.

NFS allows a power fail on the file server, and have the server rebooted (after possible repairs), without affecting clients (except for a potentially long delay in calls).

But then, users complain "NFS causes my application to hang up". Basically this move problem cannot be solved without an end-to-end solution. Which isn't in the CIFS/SMB design. Which is also why I am frustrated that Microsoft doesn't include an NFS client fs (I don't know about Apple).

(And, it forces me to put SAMBA on the file servers as well).

5. just because a problem was solved 25 years ago

[Anonymous Coward]

doesn't mean todays hot shot 80 grand a year 'senior software engineers' will think to test against it.

Very unfortunate because it penalizes "switchers"

[5n3ak3rp1mp]

Old-hand Mac users like myself have not even developed any sort of habit yet to use the "move" command since it is relatively new. The procedure has always been: drag to make a copy, then delete the original manually.

But Windows has had moves for much longer, so users who start there expect it to work the same over in Apple territory. Wham!

PEBCAK

[Doctor O]

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. Oh boy. You click "OK" on the dialog that FUCKING ASKS YOU TO CONFIRM THE OVERWRITE and it DOES IT?

The HORROR!

I can already see the headlines: "USER TELLS COMPUTER TO DELETE STUFF AND COMPUTER DELETES STUFF".

This must be among the most stupid things I've ever read on Slashdot. And while we're at it, your statement applies to Windows, Konqueror and Nautilus, too - which file manager does merge the contents? None that *I* know does. No, Windows doesn't, no matter you are claiming in your post.

Re:PEBCAK

[Anonymous Coward]

Uhhh you are an idiot.

STOP

[anomaly]

The fact that someone mentioned complexity associated with command-line actions means the conversation is over. Apple's model for file copy has NOTHING to do with the command-line, switches or flags. That complexity is abstracted from the customer.

rsync is VERY powerful. VERY powerful. In order to glean benefit of that power, you have to be educated about how to use it. Could Apple have defaulted the app to use the "include apple-specific-stuff?" Sure. Should they have? Probably.

Regardless, rsync is HARD and complex for "joe sixpack" and it's not simpler for him to run
rsync -e ssh --recursive -l -t -g --compress * joe@destination:dest_dir

than it is to run
rsync -e ssh --recursive -l -t -g --compress * joe@destination:dest_dir --includeAppleSpecificStuffHere

It's the same to them - all gibberish.

Re:STOP

[dreamchaser]

Were you born without a sense of humor, or did you lose it in a tragic childhood accident?

Apple needs some help

[Anonymous Coward]

Maybe Steve Jobs should get the guys at Microsoft to check over their code. Sounds like they can use a bit of help, since Apple's Quality Assurance department isn't assuring quality.

But hey, what good is grossly overpaying for a computer, then a service pack, if it doesn't break all the time? When you have either Apple or Teh Lunix, you need to carry that cross on your back. And make sure everyone knows it's there, of course- it's not worth using teh lunix or Apple unless you make sure everyone who will listen knows you are using teh lunix or Apple.

Woosh

[Anonymous Coward]

Woosh

Why not rename?

[spitzak]

Why not rename the old folder to "old version of name" or something like that?

I agree with several posters here that the Mac is being more consistent but I also agree that it can destroy a lot of data.

Several have stated that dragging the contents of one folder to another will duplicate what Windows does, but this is not true. If there are subfolders it will replace them in the destination, while Windows (and rsync and cp and tar) will merge the contents of the subfolders.

Something that would be consistent would be to have any attempt to replace something of the same name pop up a question box that asks what to do. The exact same question would be asked for *both* folders and files:

replace = this is what the Mac does all the time, and Windows does with files

don't replace = don't make any change

rename old one = rename the old copy so it does not interfere with new one or any other files.

rename new one = rename the new copy

merge = this is what Windows does with folders. However this could be applied to *any* file, provided the program that owns the file knows what to do. I could imagine a user wants their Word documents by the same name concatenated. If merging is not possible then it does rename or something.

It will pop up this file for every file, and if merge is selected it will recursively pop up this box for files inside the merged folders. Add the Windows-style "do this for all files" checkmark so the user does not have to put up with this.

Re: mv

[Anonymous Coward]

I'd be very worried if Finder actually called command-line utilities to perform things like this, as it's not generally good design Hellos? This is a Unix philosophy (see http://www.faqs.org/docs/artu/ch01s06.html) "Write programs that do one thing and do it well. Write programs to work together. [...]"

Renaming on the same device (partition) may be trivial using the rename() system call but copying between devices isn't especially if you want good performance and in any case it's hardly worth the effort to reinvent the wheel err mv. The overhead of exec() clearly does not matter in this case as it's completely neglible compared to the human latency and you can see that you don't need to execute mv once per file but only once per selection. In fact, many file managers do exactly that. They use cp, mv etc.

LOL

[Anonymous Coward]

Apple bug - "Oh it's ok it'll be fixed soon." "No big deal, you can just work around it"
Vista bug - "OMG hahahah Windows sucks!!!" "Vista is horrible, they can't even program"

Keke

From Apple's Discussion forums

[IwarkChocobos]

http://discussions.apple.com/thread.jspa?messageID=5766747&#5766747 It's been around a while now...which is scary. I love my mac's but that's not a good thing to keep in the system. This is NOT a fix, this is just annoying.

Guilt?

[Anonymous Coward]

You mentioned Apple and something sexual in the same para. By default, Apple fanbois think you are saying they are homosexual. Probably, guilt conscious. Just watch what happens to this post! 3...2...1...

I'd make a comment...

[PHAEDRU5]

...but I don't want the Zealots of Mac (tm) to mod me down to -1, Flamebait.

so you over ride the default behavoir and get bit?

[Anonymous Coward]

Sheesh, whine whine bitch bitch.

it's Mac OS X, in order to run into this bug, you have to override the default behavior of the OS.
if you drag and drop from one valume to another it always copies. then delete if you want. if the extra step of changing the behavior to move feels faster than the extra step of delete then cheers to you finding it.

Dear Apple Applogist Fanboi

[Anonymous Coward]

Dear Apple Applogist Fanboi

What took you so long to make a splashing entry in this thread apparently discussion something bad about Apple and Mac? Perhaps, you were listening to cool funky music on your cool funky ipod drooling over cool funky Steve Jobs' speech on your cool funcy iphone. And thats perfectly fine.

And thanks again for enlightening all of again that the fault is _ACTUALLY_ with Windows again. Mac OS is perfectly fine, and just works.

Regards,
A Windows luser

More ways to lose your data on Mac OS X

[ernst_mulder]

I found another one (well actually one of my customers did, by accident). It has been around for some time now.

Imagine the following scenario:

1) Mount a CD (or network volume, firewire disk, etc...) and copy the files you want to work on to your Mac. You can also duplicate an existing file to work on a duplicate.

2) Go to the program you want to work in and open the files (don't doubleclick them in the Finder, open them _from_ that application!).

3) Do half a day worth of work in that program (not essential to reproduce this bug, but that's what my client did). Save your work.

4) Then go to the Finder and accidentally press Apple-Z (undo). Then watch in horror as you see all your modified files disappear into nothingness...

(I would expect the Finder would be able to see the file has been modified but it doesn't take that into account.)

Verified in 10.4.10. Haven't got 10.5 yet, maybe you can try it there?

I've sent this to Apple (although not "officially" as a bug but as feedback) but so far the problem is still there.

Tigger TM&© Disney

[tepples]

If Apple had called it Tigger

Then it would have rhymed with "gold digger" and with a word considered offensive.

Furthermore, The Walt Disney Company manages a famous fiction franchise "Winnie the Pooh" that includes a character named Tigger. This franchise generates more revenue than the Mickey Mouse franchise that Disney originated. Because Apple introduced Tiger (April 2005) before Disney bought Steve Jobs and Pixar (January 2006), there might have been a lawsuit had Apple used the "Tigger" name at that time.

Re:Tigger TM&© Disney

[Hal_Porter]

Woosh!

linuZZZ, winDOZE, but how is "Abble" sleepy?

[tepples]

His only other joke is "Linuzzz". Not much better. As far as I can tell, Linuzzz is a response to everyone else's "Windoze". But at least "zzz" and "doze" both bring to mind sleep. I don't know what "Abble" is supposed to mean.

A(nalog) hole

[tepples]

wouldn't a hole where Mac files come out be named after Apple? Ie: The A-hole? No, A-hole is taken for the analog reconversion vulnerability, which exists in any digital restrictions management system used for noninteractive works.

Never move, copy, verify & delete instead

[MMHere]

That's what I've done since the earliest years of PCs such as the TRS-80: copy the directory to the destination, check that it all arrived, only THEN delete the original.

I don't see what the big deal is about ____

[Bushido Hacks]

I mean, its not like anything important is going missing like _Deleted_ or _Deleted_ or _Deleted_. Heck, I never really needed _Deleted_ in the first place. But I will miss that _Deleted_ on my _Deleted_ that I shared with _Deleted_ at the _Deleted_. I doubt any of that was work safe or even legal. At least it wasn't _Deleted_ or _Deleted_ or _Deleted_ or that stuff on _Deleted_ where they _Deleted_ or IRC where _Deleted_. Man those people are sick _Deleted_ in the head.

works for me

[softweyr]

I've been using rsync to back up 3 macs (g4 mini, g4 ibook, macbook) to the same firewire drive for years, on 10.4.

Perhaps in your father's case PEBKAC?

not PEBKAC in this case

[Anonymous Coward]

I don't have the error message handy, but rsync would puke with nasty internal errors, consistently, on the same four or five files out of the tens of thousands it was operating on. Google confirmed that it was a problem with Apple's build of rsync, and investigation of other rsync builds turned up no viable solution, i.e. all the other builds had their own shortcomings or missing features too.

--fw, on another account

Jeez, get over it. This'll be fixed...

[Zhe Mappel]

...presently, however, the entire Apple campus has more serious concerns. Namely, debating whether to make the new reflective dock more opaque and less reflective, or more reflective and less opaque. No decision will be made in this more pressing matter until all viable options have been weighed and cross-checked violently against the Human Interface Guidelines by interns prepared to impale themselves upon the nearest pixel for The Cause, or until Steve Jobs has a screaming jag and fires some poor sap who didn't genuflect long enough. Whichever comes first. For now, don't move any files, mmkay?

Data Loss

[relikmu]

Its been like this (loosing data while transferring things to a device that disconnects) for a while they do need to fix that part of finder. People have been literally screaming for it.

Apple fixes potential data loss wit OSX 10.5.1

[itsybitsy]

A bug update from Apple for MacOSX 10.5.1 arrived this morning. Looking down the list we find the following relevant fix noted:

"System and Finder: Addresses a potential data loss issue when moving files across partitions in the Finder.".

Let's start testing it boys and girls and report back on how it went... Thanks.

http://docs.info.apple.com/article.html?artnum=306907