My friend Rasmus told me about this ‘little’ deficiency in OS X a while ago, when something similar happened to his parents Mac. And it is perhaps the stupidest thing I have ever come across in an OS.
Now hold on to your hats:
In my local WordPress 1.3 folder, where I’m currently working on 4, I obviously have a wp-content folder, inside which all my theme files reside. After asking on the WP hackers mailing list about a new function, I figured I’d give the latest nightly a run for its money, and so I downloaded and extracted it, opened the folder, selected all the files and dragged them into my local WP13 folder.
What do you think will happen?
I’ll tell what’ll happen, and what just happened. In OS X, the new wp-content folder will replace the old wp-content folder completely, throwing out everything inside of it, replacing it with the content of the new folder, keeping nothing from the old folder. And while you can undo the action, moving the new folder back where it came from, that won’t undo the deletion of the old folder!
So you’re up shitcreek without a paddle, hands tied behind your back.
This has got to be the most fucked up braindead ‘look at me, I’m a moron’ way of doing things I have ever come across. User data is sacred you fat fuck of an OS! How the hell did this ever make it past the desk of whoever decided that it would be a good idea? And how in the world did he keep his job?
Luckily I had 5 – 6 files open in my editor and a backup on the server, but I’ll wager I’ve lost at least a days work…
I believe that if you hold down the “o” key while performing the copy, the behaviour is adjusted so that only duplicate files are replaced.
Files on dest that are also on source are replaced;
Files not on dest that are on source are added to dest;
Files that are on dest but not on source are untouched.
If I remember correctly.
No. Way.
That sucks, really, really sucks. I was actually looking forward to seeing new clothes this sunday.
Sincere condolences from Amager, and best of luck with what happens next.
Jonathan, good to know that there’s an alternative, but seriously, I wonder who the hell concocted something so ineptly daft! :(
Thanks for tidying up my comments Michael. Can you test that behaviour (I don’t have access to an OS X machine here) just in case I’ve made a complete arse of myself with incorrect information?
You’re right, it does “feel” wrong that folder copying works that way.
Shame it’s put you back a day. Like Joen, I was looking forward to 4.
Jonathan, I can’t seem to get it to work. I’ve tried both hold down ‘o’ while copying and moving. Both with no dice…
Arse! That is very unlucky. I was looking forward to 4 too.
What version of OS X are you using Michael? Are you copying to and from the same disk or are multiple disks involved?
I’m on the latest of everything in Panther, and it’s all on the same disk.
My comment (#1) should be disregarded. Sorry Michael.
so you replaced one folder with another, not the contents?
sorry but to me, if im follwoing correcty, thats normal behavior. as far as the OS is concerned youre replacing the folder not the contents so it replaces the whole folder.
Should this really work any other way?
Or maybe not…
I knew I’d seen this referenced before: http://www.peachpit.com/articles/article.asp?p=30341&seqNum=8
I may have misunderstood. In which case, can any explain what the “o” modifier does during a copy?
err, sorry you lost the whole of v4 though, i was looking forward to seeing that.
im also running a local install of the latest 1.3 and am trying to upgrade my current site to 1.3 themes but its a tad complicated.
Im also running 1.2 locally for testing and a mirror of my current site for nor real reason ;-)
WP needs to be easier to upgrade really, ive not touched my live install since ‘accidently’ updating it to an old version of 1.3 for fear of breaking it all.
If there can be some web based automated service that only replaces necessary files and backs up those it does replace or something.
From the article linked in comment #11:
“When you drag an item to a location on the same disk, the item is moved to that location.”
So a move, not a copy is performed. Thus the replacement of the contents is the correct behaviour.
But, “when you hold down o while dragging an item to a location on the same disk, the item is copied to that location.”
With the “o” modifier a copy should be performed and the behaviour should be as Michael expected.
i think o means option or alt.
this basically just makes a copy rather than moving, to get the option to replace files or not you have to copy the [i]contents[/i] of a folder then the OS will check each item and ask if you want it replaced.
Im not aware of a way of doing this where it checks everything in every folder but it would be useful if anyone knew.
Thanks for clarifying that Matthew.
matthew, I think you’re right from a purely über-pragmatic point of view. If you have a shed with tools in it, and you remove the shed, obviously the tools will be gone as well, unless you take them out of there before you remove it.
But people as such aren’t ‘über-pragmatic’. When throw a new shed into my imaginary garden, I damn well expect to keep my old tools in addition to any tools that come with the new shed.
Enough with the shed’s. I think it’s fine if there’s a pseudo-mode that can be used to change the operation manners, however read through Jonathan’s link, I’m baffled that anyone could come up with the basic operational procedures. Drag and dropping a file should be the same regardless of whether it’s on the same drive or not…
Of course, knowing Apple on this particular area, they’ll probably keep it this way. Just like how they have enter be ‘rename’ and option-arrowndown be open… OS X is a nightmare in terms of its pseudo-modes and odd operational manners sometimes.
And just to recap, both drag-dropping and option-drag-dropping will replace the folder.
That is really bad behaviour. I can’t believe Apple messed up like that.
So, the only way Michael would have got this to work as he expected, would have involved copying individual files manually?
That just sucks.
yes it will.
Maybe Ive used the mac so long im used to this behaviour but I dont understand the confusion. Does windows work differently?
Basically drag from one drive to another and itll make a copy of what youve dragged in the new place, hold option and itll move it (or delete it from the original drive). copying from the same drive to the same drive then option basically reverses the behaviour so that rather than moving it duplicates it.
Its never occured to me that you might want the OS to look within the folders when moving/copying but it would be useful, maybe in Tiger.
I believe there are some unix commands which might be able to do this though, but im not enough of a unix geek.
“enter be ‘rename’ and option-arrowndown be open” – whats that? I dont follow.
…the new fancy dancy finder apple-z SHOULD undo this though. if it doesnt then its a BIG oversight.
sorry for so many short quickfire posts.
Jonathan M. Hollin
“Does windows work differently?”
Yes. Windows works in the way that Michael expected OS X to work.
Windows will merge the two folders, regardless of whether you’re copying or moving.
This shouldn’t be an issue, as Michael says, “user data is sacred“.
Anyway, I think we’re all missing the main issue here:
Michael, how long will we have to wait for 4 now? :-)
I hate committing to anything, but I am shooting for today.
Great. Well don’t let us distract you any further.
After reading the thread i link to, the Apple way seems right to me and the windows way seems SO wrong
Im happier if im in charge of what im replacing, I dont want an OS making assumptions that i want to merge folders. but maybe a simple key modifier to enable this would be a good idea for those occasions.
When i have had to merger folders though I go through each one meticulously checking modified date and files size as I just dont trust a programmer to assume the right files need deleting or replacing.
Of course, you could just bin the GUI and use the shell:
cp –rp /path/to/source/directory/* /path/to/dest/directory/.
(copy recursively and retain permissions)
That maybe true, but it’s a grievous misunderstanding if whoever said this believes that implementing a range of ‘situational aware, but largely invisible assumptions’ is a good idea. The same line of thought probably brought Adobe to disregard the otherwise OS-wide use of CMD-H for ‘hide’ and keep their proprietary CMD-SHIFT-H in Photoshop.
One rule to rule them all! Not one rule to rule a lot of situations, though if you’re trying to do a, then it’s a little bit different, oh, and if you’re moving b to c over d then it’s something entirely different.
I agree that replacing folder has its place, but on ay to day file operations, and this may be force of habit on my side, merging is the only way to go. I’d even settle for an extra button on the warning dialog, marked ‘merge’. But outright replacing at folder-level and not allowing undo is destructive behavior.
I think a modifier key would be the way to go, just changing the behaviour would leave ALOT of confused Mac users with a ALOT of crap on their Macs.
Merging by default does honestly seem like very odd behaviour to me. After all, graphically (ie visually on screen) youre replacing one folder with another, NOT the contents.
I wouldnt expect the OS to check the contents of a document if i dropped one from one place on another and then by default merge the 2 different files (although id like the option – atleast with WP ;-) ).
it SHOULD undo though.
you could try this maybe – http://www.macupdate.com/info.php/id/9926
Ouch..
Very lucky you had some of the files open in an editor though. I recall similar situations with MyBB and i’m like “f…, I just lost the past 3 hours work!”.. Then I realize I still have the files open in my IDE..
Yes, that is correct, however this is not the same as what you do using the Finder. The Finder does not include the wildcard. Instead the Finder first removes the original directory and then copies/moves the new one in place. Default behaviour, and I feel Windows does it incorrectly.
A new copy modifier called merge should be introduced, which would allow such behaviour.
If there can be some web based automated service that only replaces necessary files and backs up those it does replace or something.
It’s called
diffandpatchand both Unix commands are built into OS X. Also, BBEdit can make very gooddiffs; it makes for extremely painless upgrades.Sorry to hear you lost your work, Michael. I am already sick of seeing this default WP theme, it SUCKS :-/ (and the comments textarea is too small!).
I would hate to say the obvious – because this definitely a case of me throwing stones at glasshouses – but critical user data should always be backed up. CD/DVD/Tape/Other HD/Whatever. I don’t do it, hence the glasshouses reference. But given you have a very cool scripting language in OSX, at the very least writing a backup routine that saves even to a different folder may be a good investment. Who knows what other nuances OS X has in store for you.
Fingers crossed for a swift recovery for 4.
Get an old PC from somewhere, preferably a PC that someone else is throwing out. You might need to buy a large hard drive. Install linux. Install rsync. Configure rsync to backup your Mac every night.
Having lost files to typos, software glitches and hardware failures, I now count on rsync. Creative people can’t afford the effort it takes to rebuild things which have been needlessly lost. And, at least in my case, some things cannot be replaced because I’ve forgotten how I achieved something clever last year.
I forgot to mention this, but OS X also comes with CVS installed. It is the best thing since sliced bread when it comes to managing websites. I have just launched a version 3 of my phpBB hacks website. Obviously, there’s always some things creeping up, but thanks to CVS I am able to
diffbetween two versions and can easily update my working copy.The other advantage of CVS, is that when you
commityour files, you automatically have a backup of them.I don’t understand how merging data is not considered the intuitive way of handling the move operation. After all, I want to move a folder somewhere else, not delete something that happens to be where I put it.
Also, I very frequently move folders to somewhere with a samenamed folder to update the contents of the target folder. Say, whenever I grab pictures from a digicam and want to add it to a picture folder, skipping the ones I’ve already copied and adding new ones.
And no matter how I look at it, I also consider user data sacred, and it sure as hell shouldn’t be deleted beyond recovery without prompting me.
And I don’t just say this because it’s “The Windows Way™”, but because I honestly think move should move, not replace and in the end, it’s files that are the most important to the user, not the folders in which they are stored.
I never thought of the described bahaviour as bad. Interesting viewpoint that merge should take precedent over copy/move.
To me it sounds totally logical, that the moment I cut the filetree at a certain point the tree is rebuilt from that point on with new content (that’s why there is a dialog at the beginning of the copy/move process asking me to confirm this possibly dangerous operation).
Martin Andersen described the Windows way pretty nice. In MacOS you select all the files inside the folder and drag them into the picturefolder. you then click in the dialog box “don’t replace files of the same name” – same effect, different way.
A question: if my camera always restarts numbering the files, will windows try to replace the files in the picturefolder that have the same name? if it does, isn’t this really, really bad? (especially if you think files are sacrosanct)
To me the filetree cut operation seems more logical, especially since merging is more complex and would justify it’s own interface.
But yes a more sophisicated merge interface in OSX would be great.
I would expect things merged, and I wouldn’t expect a folder to be considered a single entity. I’d expect a folder’s contents merged and when it came to files that existed in both, for it to ask me if I want to replace the item.
I did an experiment copying several items from one folder to another. Both folders contained a sub folder named “cookies”, and several other documents with different names. It moved the files over, not deleting any. When it came to the folder named cookies, it treated it as a single entity, just like any other file and presented me with this:
“An older item named ‘cookies’ already exists in this location. Do you want to replace it with the newer one you are moving?” with “Stop” and “Replace” buttons.
As I expected, clicking “Replace” removed the older cookies folder and put the new one in it’s place, contents un-merged.
My question is… did Mac OS not give you a similar warning before replacing the “wp-content” folder? If it didn’t warn you, that is pretty stupid, but I know of no way to turn off these file replacement warnings. If it did ask, and you clicked replace, what happened is exactly what it told you was going to happen. One folder, in it’s entirety, got replaced with another.
I understand your frustration. It really sucks – however, being a 15 year Mac user and developer, that has always been the behavior I was accustomed to. There was a program in the 90s by Connectix called SpeedDoubler that did the behavior you wanted. Maybe this is an add-on someone can make yet again (an add-on that modifies the Finder’s behavior).
However, the prompt you get is very clear – you get a warning that says the item or items will be replaced. It does not say it will merge, it indicates nothing like that. So while it sucks that you had to experience this behavior, it is the behavior you are explicitly told will happen. For anyone who has not come from a Windows background to begin with, this will be what they expect as well.
Despite all this, Apple SHOULD have somehow implemented an undo for this kind of operation.
Eytan, but is there a way of ‘merging’ the two?
Unfortunately, not through the GUI. There are replacement shells (say like pathfinder) and a Unix copy does what you want and expect – and lastly, I am sure someone wrote an AppleScript out there that would do it (I am looking now) but that is not the native way and without an add on it is not really doable. This has always been a frustrating thing for me, but in all honesty, I rarely come across it (so yes, it is frustrating the one or two times I deal with it).
You might want to check out http://www.cocoatech.com/ for Path Finder, a Finder replacement that may do what you want.
I suppose the greatest issue I have with this, is the fact that it’s different from what I would expect. I just hope that I’ll remember this the next time I’m moving stuff around.
I am amazed though, that Apple has neglected to offer an option for something so basic.
I am more amazed that people really expect this type of bad behavior from Mac OS. The truth here is the Microsoft method of merging the contents of two different folders to create a new, bastard folder is simply bad UI design. It’s unreasonable to expect that the operating system won’t replace an item with the same name, when that is most common need! I don’t think Apple should change anything about how copies and moves are done in Mac OS X. What Apple should do is implement full Undo functionality in the Finder, so that under all circumstances, no files are lost by a single copy/move operation. Apple could go further and support multiple Undo. Beyond that, Windows users just need to learn the right way – they’ve been doing it the wrong way too long as it is.
I wouldn’t call it bad behavior. It’s just different expectations.
It doesn’t create a new, bastard folder. It does what the user expects it to do: move the contents of This folder into That one. Not once have I ever thought, “I want This folder to replace That one.” If that ever happens, I’d rather the OS just let me delete the old folder myself.
The author is acting like he was not given any warning. When an action that he describes is taken there is always a warning dialog box that explains exactly what you are about to do and requires confirmation.
I have managed many Macs and Windows Machines for many years and I agree that the MacOS default behavior is best. What is really wrong is that Apple has never added the option of merging the folders as windows does. That dialog box which the author obviously ignored could very easily add a third option that would merge the folders the way the author is used to.
While I strongly disagree that the windows way if the correct default behavior I just as strongly believe that it should be an option. There are often times where it would be useful.
Also an Undo would also seem quite logical.
‘The Author’ also thinks that Apple’s failure in making undo function is pretty grim.
I believe merging is the wrong way to go…! I think MacOSX’s way is more logical…but needs to be better! I would like to see the replaced folder/content in the trash can! =)
That is also a nice way of doing things, along with a proper undo.
Look at the MacOS X way of copying/moving folders like this…
Suppose you’re moving house. There are boxes full of stuff in the moving truck already, one of which is labelled “books.” Suppose you have another box labelled “books” ready to go in your living room. If you ask the mover to take the box in your living room and replace the one labelled “books” in the truck, they are going to remove the one in the truck and put the one from your living room in its place. They aren’t going to look through the contents of the box on the truck and only replace those books that are the same in both boxes.
If, however, you opened up the box in the living room and instructed the mover to take all of those books and put them into the box in the truck, replacing duplicate title with the new ones, that’s a completely different operation.
The Finder treats a folder as a single entity, just like a mover treats a box as a single entity.
I think I get it by now ;)
The Mac copy method, without at least an option to merge or a stronger warning stating that the FOLDER will be replaced, is a greivous sin against all humanity. Or at least the 5% that use Macs.
Take the above example— What if you’re building a house on the same lot as your old house. Would you just tear down the current house, with all your possessions still inside, then build a new house in it’s place? You might do just that if all your old possessions were crap, but I’m guessing you’d want to keep some of your old stuff.
If someone takes their new year’s tax information (which is politely placed in a nice manilla file folder) to the accountant, and he goes to put it in the file cabinet, should he just throw out the existing folder and put the new one in it’s place? I’m guessing the IRS wouldn’t consider that good form in a few years when they want to audit.
Just because “That’s how it’s done on the Mac, get used to it”, doesn’t mean it’s right. Adding a merge option and better undo functionality wouldn’t entail significant work, and it would make users happy. And that’s really all that should matter.
Hell, I’d rather that the merge functionality, instead of only replacing files or not copying files, had an option to copy ALL the files, but any with the same name would have _001 appended, or something to make them unique.
But we really shouldnt be trusting computers to make the sort of decisions they need to when merging folders you know.
Itll all end in some kind of dystopian sci-fi future hell with machines in charge – and apparently itll be Windows. No, stop this future now!
sorry for what happened.
for me that’s normal behaviour. i would be really surprised and confused if it would work otherwise. what you’re asking is syncing, which brings up several more questions. is the operation a mirror (deleting orphans) or an update (creating a mixture of the two folders)? what is considered as a new file – is the content of the file checked or just the modification dates? etc.
i feel this is definitely not a mistake by Apple, but a conscious design decision. i’m still trying to get my head around why do you expect sync instead of replace…
For those wondering what exactly a ‘merge’ operation, or rather, the way Windows does it, is:
Any file that already exists is overwritten with the new one… Easy? Yes, I think so.
As a Windows user despite the fact that the OS will merge folders I always go into the folder and select all before copying or moving into an already open destination folder. This makes more explicit what I want to do, whether the OS understands a folder merge request or not. Drag and drop is a very powerful tool – the simple act implies all the rules discussed above in one quick drag of the mouse – not best when concentrating on design as opposed to filing.
For vital stuff I always do Ctrl-C, Ctrl-V (copy, paste) in Windows which creates a copy of the folder in the same parent folder.
Then again, I have managed to overwrite a complete new stylesheet in Dreamweaver by clicking close and ‘Y’ when the file was already saved! Web design is such an immediate thing that we tend not to stop and think as we should…
Hindsight is a wonderful thing.
What I don’t understand, from you people who believe OS X does it right, is: FTP transfers work in the Windows way as well, right? And AFAIK, so does Linux… So is OS X the only one doing it right, or…?
Michael, I was just about to make that same comment. I understand where the others are coming from, they are looking at it largely in a graphical sense. But coming from the PC realm (since you used to be on PC, right?), the GUI is considered to lay on top of the OS; so we look at them as files. Even folders are just a special type of file.
When you look at them merely as the icons on your screen and view folders as containers, it makes sense that a replacement would take place. But for those of use who view them as lists of files, that drag-and-drop copy command is nothing more than a graphical representation of a shortcut to instantly perform the copy/move command on all objects involved. I hope that makes sense to all of you.
Personally, I’d like to have the option for both, but would want the merge to be the default (which really makes the most sense file system and OS-wise).
Exactly.
And yeah, Mac OS is the only one that does it that way. That I know of, at least.
I do think OS X version is the correct one, why would a folder be different to a file and have a different behavior ?
As for FTP, Windows and Linux working the same way, only two are really graphical and both came AFTER Mac OS, so who’s doing it wrong ?
:-)
I don’t think you can seriously consider time of release a winning argument. Often, quite the opposite in fact. And even so, I think we could quickly scratch the surface of Mac OS and find large 20/20 hindsight stupidities.
There you go again, Michael. Why do you always have to ruin the fun by injecting reason and logic into a topic that so badly wants to become a massive flame war? ;)
Yeah, I don’t know… Bad habit I suppose.
A merge feature in OS X sounds nice.
But having the Finder do one thing when you drag files and another thing when you drag folders seems illogical. After all, even folders are just special types of files, right?
Try a pop-quiz with some genuinely ‘average’ users about drag and drop behaviour: I am betting most of the Windows can’t tell you, and the Mac users can.
Sorry for your loss. But getting a second harddrive and Chronosync or rsync etc. to create a copy of your home folder twice a day would be a good way to turn this into a positive exerience. It feels worse each time it happens. ;-)
There is one slightly okay fix to this problem.
You can download muCommander for MacOSX. It’s free. Google it.
muCommander is just a tool similar to the old Norton Commander. When you copy files with it, it gives you the options:
Ask
Cancel
Skip
Overwrite
Overwrite If Older
Resume
“Overwrite If Older” is nice.
The MacOS way of doing things (clobbering the entire directory on a move or copy) primarily has to do with how Application packages are maintained. Each Application you use is actually a nice self-contained directory. When you copy Applications into your Applications folder, it would be bad to merge these “Application folders.”
For me, merging is nice because I have a Documents folder that I maintain on multiple machines. Let’s say I have a folder called “School” in which I keep folders like “ECE 858” that each have subfolders like “Homework 1” and “Homework 2”. Let’s say I go somewehere with my laptop and work on homeworks 3 and 4. I then come back to my desktop a week or two later and want to sync the files up. It would be nice if I could just drag the “ECE 858” folder to my Desktop and have it merge the two folders.
This gets more complicated when I update a few files on my laptop and want to merge the changes to my desktop. In Windows when I do this, it prompts me when I’m about to overwrite, and it TELLS ME IF THE SOURCE FILE IS NEWER THAN THE DESTINATION. This way I can easily merge a folder from another machine and only overwrite old files.
So muCommander on MacOS does OK for me. It allows me to copy from local folders, FTP folders, or SMB (Windows file sharing) folders. The problem is when I want to transfer from SFTP folders. In that case, I have to use SFTP to get the folder on my system, and then use muCommander to do the merging.
(the other option is to mount my MacOS folder on a Windows machine and do the merging on Windows INTO the MacOS folder…)
As a Windows user, I regularly rely on the “merge” behaviour when tidying up folders, so I was rather surprised to discover this outcome when dragging an empty Final Cut Pro capture folder into the same space as a capture folder containing seven tapes worth of media. Whoosh! All gone. Time to start re-capturing. The full implications of the warning message (“An older item named “Capture” already exists in this location. Do you want to replace it with the newer one you are moving?”) didn’t even sink in, so ingrained is the “merge” behaviour in my work habits. So wishful was my Windows thinking, I took it to mean that older “items” within the folder would be replaced with newer “items”, not that the state of a full folder would be transformed to that of an empty one.
Extending the boxes analogy, when I move an empty box to occupy the same space as a full one, I don’t expect the contents of the full one to dissappear.
Stephane writes: “why would a folder be different to a file and have a different behavior?”
Folders should be treated differently because they represent containers of files. Calling both files and folders “items” is too vague.