Skip to Content

Longstanding "move files" issue has alarmed Leopard users

Update: Having tested this on both Leopard and Tiger, I now agree that the Leopard issue is more serious than the Tiger issue. Under Leopard, instead of just a file in progress disappearing, the entire source directory may be lost if a move operation is interrupted -- the only fix seems to be a Terminal 'cp' of the source before the Finder error dialog is cleared. Until we have more details from Apple on the scope of the problem, do not use the Finder to move files -- copy instead.

The Mac-loving web is abuzz with reports of a problem moving files in the Leopard Finder. If you're saying to yourself, "Moving files? You mean copying files, don't you?" -- nope, actually moving files, done by holding down the Command key while dragging a folder or files from one volume to another. This trick, a lightly-documented holdover from OS 9, can come in handy if you really truly don't want to leave a copy of the files in the original location; perhaps you're intending to delete them anyway, and this is one step instead of two. The inverse trick, forcing a copy instead of a move for intra-volume file drags, is done by holding down the Option key while dragging -- note the presence or absence of the green + icon telling you whether the files will be duplicated in the target or not.

Anyway, the aforementioned bug in the Finder is this: if for whatever reason your target disk gets disconnected during a file move -- a USB or Firewire cable is yanked, power failure, or a network interruption for a remote server volume -- you're likely to have problems with your moved files. In particular, whichever file was in progress when the connection dropped may disappear from both the source and target folders, never to be seen again. This is understandably upsetting and certainly cause for alarm and fuss, except for one minor point: this isn't a new problem in 10.5. The issue with file corruption or loss during a move goes back at least to Mac OS X 10.3 Panther and quite possibly further. A recommended workaround is simply not to move files; copy them, and then go back and delete the originals if desired.

What does seem to be compounding the issue for some Leopard users is instability in the SMB networking stack. If remote NAS or fileshare volumes are prone to dropping off mid-transfer, then the issue may be presenting more often than it had in previous systems. Some readers have noted that this is particularly troublesome if you're trying to clear off a drive for backup use -- au revoir, old files, au revoir.

While we strongly suggest not using the "move files" trick for anything critical, and we'd dearly love to see this issue fixed in the Finder, we also would like to gently remind our readers that everything that goes wrong is not necessarily, automatically, decidedly Leopard-related.

Thanks to everyone who sent this in.

Categories

Troubleshooting Leopard

Update: Having tested this on both Leopard and Tiger, I now agree that the Leopard issue is more serious than the Tiger issue. Under...
 

Add a Comment

*0 / 3000 Character Maximum

52 Comments

Filter by:
Michael Rose

FYI, I believe this bug has been fixed in 10.5.1.

November 25 2007 at 1:07 AM Report abuse rate up rate down Reply
Brad

i wish i read this oh, 30 minutes ago... thank god for time machine

November 08 2007 at 12:48 PM Report abuse rate up rate down Reply
Joe

This is an embarrassing problem for Apple, especially since it is built on a solid unix system. One of unix's strong points is that it is a collection of very small tools that can be chained together with pipes and redirects.

If the move command was built by combining copy and delete, it could be represented as "if (copy $1 $2) rm $1; else rm $2" (pardon my pseudocode). Meaning, perform the copy, and if the operation is successful, delete the original. If it fails, remove whatever was copied to the destination (like rolling back a transaction).

I don't consider myself to be an expert programmer by any means, but if I was in a position of creating the move command, I'd follow a procedure like the one above. If I couldn't implement it correctly, it wouldn't be available to the user.

Let's hope Apple reads sites like this and realized how much this concerns us.

November 07 2007 at 9:19 AM Report abuse rate up rate down Reply
Rowan

This is a serious problem. I'm a complete Apple convert, but this sucks. I lost 70 gigs of Data whilst reorganizing things to make room on a drive to then enable Time Machine, ironic...

There were no errors on the disk (had repaired earlier with Disk Utility) and I was simply moving a folder from one USB2 drive to a Firewire one (or the other way, can't remember) It bombed out with an error, I clicked ok, and the WHOLE folder was gone on the source, but only half it's contents existed on the destination!

Then i tried a few different data recovery programs, but they only allowed recovering the data that i had deleted from the drive earlier, not the contents of that folder. However OSX destroyed it resisted casual data recovery. Luckily the data whilst most annoying was not mission critical, merely movies i'd time consumingly ripped from my DVD collection to stream to Apple TV.
Fix this Apple, NOW, or release a software update to disable the move operation until this is fixed if you can't get it working now.

I won't ever go back to windows (unless things change a big way well down the track, ie Win95 vs System 8, i felt at the time Win95 had passed Mac OS) but this is seriously basic stuff, this is basic OS stuff, I can't believe this bug exists.

PS I love my iPhone :)

November 07 2007 at 7:46 AM Report abuse rate up rate down Reply
Adrian vG

I never knew that you could move between drives in Mac OS :-O I've looked, but only in the most basic places. And now that you tell me, you scare me from doing it :)

November 07 2007 at 2:44 AM Report abuse rate up rate down Reply
Randall

has anyone else had a problem recreating this problem?

November 06 2007 at 11:52 PM Report abuse rate up rate down Reply
wheels

If the files are important enough, they should never just be plainly moved from one volume to another. I always copy/delete when moving files. When I'm sure the copies are good, then I delete the source. It may take an extra minute or two (whooptidy-doo), but to me it just seems like better practice.

November 06 2007 at 11:48 PM Report abuse rate up rate down Reply
Dave

Frank - if you can't see the humor in calling someone who goes by the nom de plume of Frank Furter, aka frankfurter, aka a hot dog, then you really are an uptight person, and the only Troll here.

You're quite the "my way or the highway" kind of guy, aren't you? You don't like Windows, and anyone who has anything that isn't 100% anti-windows is a troll to you. Get over yourself, buddy, it's just software on a computer. If something so simple as this can cause you so much hatred and vitriol, then I think you need to get outside a little more often, seriously.

I'm not going to go reinstall Windows just to prove you wrong, as this is just about all the time and attention that your trolling is going to get from me, but I'll say it again. Windows does some things better than OS X. Whether you like it or not. I'd never go back to Windows unless OS X really started sucking and Windows became a more viable option than Linux, but at least I am mature enough to admit that the OS I use isn't the best at everything, and you know what, I am also mature enough to just live with that fact. I'm not going to lose sleep over that fact, and if yo are, you need help.

I'm not the only one to recall from my Windows days that a failed move of multiple files was not an issue because the files weren't moved until the batch completed, but I wouldn't bet my life on it either. IT WAS NEVER AN ISSUE FOR ME. I'm sorry that offends you so much.

So, in your 8,000 files exampe, even if you're correct, let me make a suggestion: DON'T DO THAT. Try copy and paste, then manually delete. Problem solved. That doesn't mean that a MOVE for smaller numbers of files doesn't make sense. I doubt the typical user is moving that many files.

There's another solution for your failed example as well. Instead of trying to figure out by hand what files moved and what didn't, why not copy them all back to the original source, select "do not overwrite" and "apply to all" options. Voila, all your files are back in place, and you can start all over again.

All of that aside, this is serious bug in Finder's move operations. We can debate all week long whether move should be an option in the first place, but Apple offers it as one, and it is causing people to lose files. They need to fix it fast, or disable it.

That's the last feeding your hot dogging trolling's gonna get from me. Take care.

November 06 2007 at 10:51 PM Report abuse rate up rate down Reply
Bob S.

Chris, I have no doubt you've chosen Night Train over Kool-Aid. If my point that one should copy and then delete the files is different from your later claim that one should copy and then delete the files, you're right; you didn't agree with me. I'm at a loss where you think these "other steps" are coming from. But seriously, don't explain it. I don't care.

November 06 2007 at 10:44 PM Report abuse rate up rate down Reply
Chris Bell

"If you MOVE them, the ones that made it to their destination are GONE from their origin."

But at least they aren't tossed into the abyss. They can still be retrieved from the destination and the files that were on the source at the time there was a disconnect are still there.

November 06 2007 at 8:38 PM Report abuse rate up rate down Reply
Buy an ad here

Hot Apps on TUAW

Tweets

© 2012 AOL Inc. All Rights Reserved.