Filed under: Troubleshooting, Leopard
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.
![TUAW [Cafepress]](http://www.blogsmithmedia.com/www.tuaw.com/media/tuaw-cafepress-promo.png)
Reader Comments (Page 1 of 3)
Rob said 1:36PM on 11-06-2007
"What does seem to be compounding the issue for some Leopard users is instability in the SMB networking stack."
Yes, bugs compounding bugs is always a matter of concern. This shows you what happens when a well known bug for MANY years is not addressed. Come on Apple. Wake up and fix AT LEAST one of the bugs....
Reply
Austin said 1:42PM on 11-06-2007
That's what they invented time machine for!
Reply
Stephen said 1:56PM on 11-06-2007
I wonder what happens if the time machine volume gets disconnected or fails during a backup? Do all of your changed files get lost? Who wants to test this out?
Reply
DistortedLoop said 2:04PM on 11-06-2007
Well, chalk one up to Windows on this one. I never lost data moving files in Windows...I am pretty sure a "move" in WinX machines is a copy-then-delete operation, that doesn't do the delete until a successful copy is confirmed.
Seems kind of stupid to delete portions of a moving file until you're sure the operation is completed properly. What's the logic in that kind of thinking?
Thanks for the option key tricks, as a switcher, I always wondered about why sometimes a drag and drop was a move, and others it was copy, and how to get around those operations.
Reply
a ham sandwich said 2:15PM on 11-06-2007
now how about they fix the remembering folder arrangements issue??!!?!
Reply
Frank Furter said 2:17PM on 11-06-2007
"Never lost files in Windows...." = troll
One thing that kills me about Windows (or XP, anyway) - try and move 10,000 files totaling 9.1GB to a 4.0GB partition. Windows will politely transfer away, until the partition runs out of space. Enjoy the rest of the weekend trying to figure out what got copied and what didn't....
Anyway, is moving files -really- that big of a secret? Maybe my years of IT has made me lose touch, but do people seriously have tons of duplicate files littered all over their drives, simply because they don't know the difference (or didn't know you could move stuff?) - or did I miss something?
Reply
Brian Reading said 2:21PM on 11-06-2007
I'd like to see this problem be fixed also:
http://discussions.apple.com/thread.jspa?threadID=1195706
It's bugging the hell out of me that I can't use my MacBook on a wireless network while on battery power. Sort of defeats the purpose eh?
Reply
Ted said 2:30PM on 11-06-2007
Thanks for posting this and clarifying for the masses. I can confirm this has existed for some time now in OSX. I experienced it (once) when trying to move my iPhoto library in Panther. Not to happy about it when it happened. So do you know what I do now? It was a difficult solution to come up with, but I figured it out all by my lonesome. I copy the files to their new location and then delete them from the old. It is so painful to have to do two steps for one task. Then again, it is much more painful to live in constant fear of data loss due to malicious spyware and virus infected email attachments. So I am willing to accept the two steps. Though, when I really want to live on the edge I hold down that Option key and throw all caution to the wind while moving important financial information from boot-drive to usb-drive to thumb-drive and ten back to boot-drive again. What a rush.
Reply
Joshua Ochs said 2:41PM on 11-06-2007
I'd like to see some background details to back up this article. Based on everything I've seen thus far, it's way off the mark.
1) This bug does NOT exist in 10.4. A similar bug existed in 10.1.3, so this looks like a regression.
2) This bug does NOT exist on the command line, so it's higher up the API stack than, say, Darwin, etc.
3) There is NOTHING to connect this to Samba. It occurs just as consistently with separate drives as network drives.
Some people are glibly saying Time Machine will prevent this. Who cares, even if it might? Data loss is data loss. No matter the circumstances, it's unacceptable and needs to be fixed NOW.
Reply
DistortedLoop said 2:55PM on 11-06-2007
Gee Frank Furter, you must be some kind of IT Hot Dog, huh?
No, I am not a troll, and if you check back through the many posts I've made in the comments here, you'll see I am a big Apple fan.
I stand by claim that I have never lost a file in Windows while doing a "move" operation. That is all I said. I won't argue about how an incomplete move will leave you hanging if for some reason all the files can't be moved, but there's a simple workaround to that, isn't there? Delete the moved files and start over. At least you haven't lost something that way.
I will also state that I've never lost a file moving them around in my two years of using Mac OS X. Apparently, though, we have fellow OS X users doing just that.
Only an Apple troll would try to take that stand that OS X does EVERYTHING better than Windows OS. I chalk up moving files easily to WinX. If you don't, no problem, but why the name calling over a difference of opinion?
Reply
Alex said 2:45PM on 11-06-2007
@4: If you're moving files in the same filesystem it simply changes the inode of the file and the move happens instantly.
I would assume that moving a file was a copy-then-delete operation. but i don't know. it's just the most logical way to do it.
my question is this: is this something that affects only the Finder, or does it affect the command line tools as well? since finder isn't open source it's hard to tell exactly how the copy/move/etc. operations are made. probably with NSFileManager but even then, how does NSFileManager do it?
If it is only in the finder, then you could simply use mv to move your files in the Terminal, if you really had a need to move them and not copy them.
because if you're on the same filesystem making a duplicate copy of a huge directory can take forever whereas an mv happens almost instantly in comparison.
Reply
Michael Rose said 2:49PM on 11-06-2007
Hi Josh --
I was able to replicate the problem on OS X 10.4.10 with a Firewire drive -- file in progress got dropped to the bit bucket. Other commenters to Tom's original report have indicated same. It's possible that there are multiple issues in play and what we're seeing on 10.4 is a different issue. When I get to my Leopard machine tonight I'll side-by-side test.
I don't mean to say that SMB is specifically implicated in the move files bug, but that since there are reported issues with SMB, anyone trying to move files to a network share might be more likely to encounter the problem.
Reply
Chris said 2:54PM on 11-06-2007
Moving files in OS X is no more a "trick" than right clicking is. The attempts to diminish this problem bug me and I am a fervent Apple supporter.
Coming from the Windows world, I see the way OS X does file transfers as grossly lacking. Not only the problem illustrated here but what also bugs me is that during a file move, none of the files are available on the destination drive until the entire operation is finished. It feels like a holdout from the single threaded days of operating systems.
Reply
Bob S. said 3:04PM on 11-06-2007
Sounds like the sensible thing to do is not to use the move feature. I've never done that, and none of the Mac users in my IRC channel have either -- for all of us, it's drag, copy, verify, and then and only then do we delete the original.
Reply
Chris said 3:10PM on 11-06-2007
I'm with Distorted Loop. Criticise Apple when it is deserved. It is deserved in this case. On Windows, when you move files, it does a copy then a delete. If the copy step fails, it doesn't get a chance to do the delete step. In case of a problem, you simply delete the files that did make it to the destination and start over. This is the safe and correct procedure for a move operation.
Reply
ACoolie said 3:36PM on 11-06-2007
I don't understand how this is such a "bug". If you are doing a true "move" across drives then the blocks of the file will be moved into the other drive. It can't simply change a number in the file flags to move it. So if I am moving a file and then the power goes off, that means that half the blocks will be on one drive and half on the other. And the way that this is done, the file is first removed from the file directory of the first drive. While the file is still "there" it won't show up in Finder.
This is technically a feature since this isn't a standard Linux feature. If you try to move a file across drives in command line, the mv command will do copy the file to the destination then delete the original. You have to explicitly tell Finder to move a file and not copy it.
Reply
Chris said 3:18PM on 11-06-2007
"Sounds like the sensible thing to do is not to use the move feature. I've never done that"
I wonder why you feel the need to go to all that trouble? Could it maybe possibly be because the built-in move function doesn't feel safe enough? This is not a user problem, it's a feature problem.
Reply
Chris said 3:48PM on 11-06-2007
ACoolie,
If it worked the way you are suggesting (and it doesn't, which shows your lack of understanding) then only one file would be lost at most if a disconnect occurred. This would be much more acceptable but that is not how it works.
If you have 100 files being moved and the connection is broken while the first file is being moved, 99 files poof out of existance on the source drive and nothing is on the destination (at least in my test).
Try it yourself, most people have thumb drives these days and it's not difficult to reproduce.
Reply
Klink258 said 4:16PM on 11-06-2007
First off, let me say that I'm not a windows-loving-mac-hater, but I'm not an expert on file magaement- File Management in Mac OS X is really bad.
Many times have I had that annoying "Moving 1 of 38 to trash" window come up, which many people just put it in their background or dock it. You think that 'stop copying/deleting/moving" button is handy, right? Well, it is. When it works. I had to log out of my computer because I had to force quit finder to stop a copying job to my iDisk- because Finder refused to relaunch.
Other than that, macs rule. W00t.
Reply
Dave said 4:27PM on 11-06-2007
Um, Time Machine?
This is a long standing bug, yes, but this is also the first time the OS has a built in tool to recover lost files.
I'm not saying the issue is any better than it is, but having used Time Machine, it really is remarkable. If the move file is indexed by Time Machine -- possibly a big if -- recovery is a snap.
Reply