Submission details
Merge folders option when copying/moving
When copying a folder to a location where a folder with the same name already exists the only option is to replace the folder (and loosing all files from the replaced folder) or stop the copy/move operation.
Add a "merge" button/option when there are duplicate foldernames while copying/moving, so the user can choose what he wants.
Medium
Medium
Not fixed
Discussion (26 comments)
Changed title from [Merge option when copying duplicate folders] to [Merge folders option when copying/moving].
Unless I'm mistaken, the "Replace" option only replaces files which already exist.
This is something that has got me time and time again. Since the default folder from a camera is DCIM, in other OSes it just created the new subfolders within when copying. In Mac OS it kill the original. thank god for time machine. The only reason I can see is when an App is updated by overwriting (sincles apps are just folders with .app at the end of the name). In this case, a merge is not what is desired. But in nearly every other case, at least for me, it usually it. A Merge button is the perfect answer to this, then diehards will be happy, but switchers won't get caught out.
abitgone - if you copy a folder containing files to a place where a folder of that same name with different files already resides, "replace" replaces the entire folder and its contents with the new folder and it's different contents, with no option to merge the contents of the two folders if they differ.
I agree this option would be great, I'd use it often.
Annoyance! ... Usability!!
Many files have been lost due to this lack of fundamental functionality. Not just my own either. And yes, not as much recently... because I've learned from my mistakes. ;)
Ideally though, they should go a hair further and implement a smarter replace option, which can replace with newer/older, or ignore files of the same size, etc.
Oh, and don't forget a SKIP option!!
Even MS has implemented that function in vista. Till XP windows merged every folder - there was no real "replace" function. That's the opposite.
Now there is a nice little dialog, which offers you to skip, replace, merge. Additionally it shows some information about the files to be replaced: change time, last access ...
It would be greate if apple "innovates" the whole copy, move and trash functions of folder.
This isn't a function, but the core behavior of Mac OS X. I did some googling after finding out the hard way after switching from windows that "replacing" a folder chock-full of pictures of a vacation made them all go bye-bye. You'll notice that almost ALL items in your Mac filesystem that are created by or related to apple, be it folders, apps, plugins, extensions, packages, iWork docs, etc. all have a "show package contents", which allows you to, for instance, look through an app's files without opening it. Essentially, they are folders that perform a non-standard function when opened (folders that run, but don't open). On the other hand, identical items not apple-related, such as Word Documents, Music files, Image files, and files from non-apple programs don't have this option. This is because all their contents are encoded in non-apple forms. So this means even if i don't have an app like aperture, i can still open an aperture library, which is a folder. So what does this mean? In unix (the very core of mac os x) anything is a file. A folder is a file. A file is also a file. A folder just so happens to be able to be opened with finder. OK, this doesn't make much sense, but I got the general idea.
Solution? I don't know, rewrite OS X? implement a high-level process that hijacks a copy operation, merges the files, then deletes the original without user intervention? blah.
Please, add to your submission: to mac OS X show the details of the files that will be overwritten! Like created data and size!
It`s sux don`t now nothing of the files, and have to stop and see the two before decide!
Look, Linux manages to merge directory contents just fine, so don't tell me about "core behavior of Unix."
This is bad design, period. It needs to be fixed.
*sigh* I'm very mad at this shortcoming of OS X after merging the contents of two old harddrives and losing some irreplaceable data.
Funny thing is, I can't think of a time when I've *wanted* to replace and not merge directories. Is this something users want to do?
Is there anyway to recover the lost files?
I know this is an old thread, but I wanted to add some detail. To rubber gune and donquikong... no, this is not UNIX behavior per se. This is simply classic Mac OS behavior from long before Mac OS X. They are simply retaining the original method that copies were done. (Although, I voted for this... I wouldn't want the behavior changed outright, but an option would be nice.)
Also, the fact that some files are bundles/packages is used more frequently by Apple, but other developers certainly have access to this functionality (I've used it myself for things I've written). It's a nice feature, and the Finder will generally treat those as single files (although you'll see the internal files show up in a copy operation).
All it needs is a "Stop", "Merge", "Replace". Alternatively using 'option' (alt) to modify it so that is changes from "replace" to merge would keep the interface clean as well.
It's a real pain when iTunes doesn't see an external drive and forgets where to store imported music so it starts saving it in a new location. Now you've got two locations with folders of music and how do you combine these two and put them back into one location? You can't without a merge function.
I'm trying the CP function in terminal right now but there's thousands of files and I have no idea what the status of the copy is.
Right now the only way to measure CP's progress is by looking at how large the dest folder is ... There was a modified version of "cp" for 10.3: http://tylers-file-cmd.sourceforge.net/ And apparently various distros have had progress flags, but I couldn't see any status options in man cp.
And the most annoying thing is how you can both interpret "Replace" as "Replace the entire folder" as well as "Replace the files within the matching folder". Vista, while using a dialogue ten times larger, at least makes it DEAD obvious what it will do when you click one of its buttons, using the file names as examples and even offering file sizes, plus the ability to keep both. The only way to improve vista's would be if I could see a preview of the operations, and be able to switch things around, before clicking Start. This would be a more advanced mode, but at least then I would know for sure if it will do what I want it to, whatever that is.
To be fair the dialog, at least in English, says "A[n] [older|newer] item named X already exists in this location. Do you want to replace it with the newer one you are moving?" - it is very clear that it is replacing the item (file or folder), I think the problem with this is that people have been used to Windows prompting you a stupid amount of times with a dialog that asked you if you wanted to replace individual files which has desensitised people into just clicking replace to get rid of the dialog. Effectively what Windows XP has is a 'merge' operation that asks you to replace files that conflict. I wonder how many read and took the time to understand what it was saying or saw "replace" and just clicked it since that is how it worked on Windows (or even Linux).
Vista's dialogue is an improvement but could do a UI designer. It makes it clear that it knows what the next files it wants to apply this to are but doesn't provide an easy ability to display that. A dialogue similar to what iTunes shows when it has issues pushing items to a device (e.g. if it can't find the item) which would show you and potentially allow you to decide if you really do want to replace those files or not.
The main issue with Vista's dialogue as I see it is that it waits until the end to nag you instead of asking straight up and presenting the option to not do the copy at all. Working this out first whilst potentially a bit time consuming and will be slow when doing it with a large number of files (need to intersect the set of each files) would be much better than waiting for it to go "oh yeah, by the way these files conflict".
In Terminal:
cp -R /sourcepath /destination-path
If you don't have rights to the folder being moved to, then add "sudo" to the beginning (requires admin account).
kiodane,
Boy does that ever appeal to... uh, designers? bah... workarounds suck.
I vote up for this. Also, for some answers on this subject, you might want to check: http://superuser.com/questions/117621/how-to-me...rs-when-copying-on-mac
I think a good solution would be to move everything non-exact-duplicate to the same folder, and leave every duplicate behind. No confirmation is needed in this case, and I can easily check the duplicates later. If it's copying merge, then the target folder will contain everything, and the source will be rather untouched. Duplicate-check is just on the file name. Leave any more complicated thing to third parties.
"Sorta fixed, in Snow leopard you can now "Keep Both", it adds "(original)" to the foldername of the older folder and copies the new folder - good but still no merging."
Where can I find this option? I have snow leopard but never get this option neither when copying or moving.
There are whole applications built around merging files/folders, so it doesn't seem like a simple task to just add a merge button. Apple could take an open source program like kdiff3 and use for such a function. Only problem with kdiff is a filesize limit around 2GB and it hasn't been updated in about a year.
@centris650: I disagree. "Merge" button should be the same like already existing commands cp (copy) or mv (move) in Terminal.
It is not a diff function, it is a copy/move with only existing files rewriting.
Last sentence is probably bad written.
I mean when I have source folder "A" which contain a file "a.txt" and somewhere i have destination folder "A" which contain files "a.txt" and "b.txt", then only "a.txt" will be overwritten by source file "a.txt" when I copy source folder "A" to the same place where destination folder "A" is. File "b.txt" remain in destination folder "A" as is. Source folder "A" is unchanged, of course.
Merge should not do any diffing. It should simply ask what to do on all individual folder and file conflicts.
For individual file conflicts, it should ask whether you want to replace, rename (either by appending a "2" to the filename or allowing you specific control over the renaming, I don't care which) or skip. It should also offer a checkbox allowing you to apply the designated action to all further conflicts within the current merge process.
On individual folder conflicts, it should ask to merge, replace, rename or skip with a checkbox allowing you to apply the designated action to all further conflicts within the current merge process and/or all subfolders within the folder being asked about at that moment.
I must admit, I do like how Windows 7 does its merging. Apple could really learn a lot from Windows' current merging capabilities.
They fixed it in Lion:
Merge folders
When you try to combine two folders with the same name, the Finder now offers to merge them into a single folder.
http://www.apple.com/macosx/whats-new/features.html
It makes it clear that it knows what the next files it wants to apply this to are but doesn't provide an easy ability to display that. A dialogue similar to what iTunes shows when it has issues pushing items to a device, but as for me, I used: http://www.istonsoft.com/free-youtube-downloader.html
Flauchhaus wrote on August 12, 2008, 11:26am
Changed problem description.