Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
Not open for further replies.
Look at my post earlier in this thread. The tar command (from UNIX) will do a merge. But you have to use the command line -- no GUI.
Hi Talmy,

Could you tell me how to use this command? Will it move the contents as it merges, or does it just copy-merge?
 
(Sigh) The mv command won't work. Witness:
Note that this does a copy instead of a move (which is safer in case of error!). You have to delete the source files afterwards.

Ooops sorry, I should've just had a look (like you said) before asking :)

When I think about it, I've done Terminal merges before and it was a really scary ordeal. You can't see what's going on visually like in the GUI, so you have to type a command, then go back to the GUI and spend ages double-checking it actually worked properly. Also, if you're doing multiple merges as you go along, you end up multiplying that painful experience several times.

What I like MUCH better in the Windows way of working is that during the move/merge, I am told about any files which may be replaced, and also a descriptive alert that actually gives me the size and date of both files, so I can choose if I actually want to overwrite it or not. All Finder tells me is the file is "older" or "newer". And it's so subtle on the dialogue you really have to think about it before clicking the button.

I LOVE the Mac. I have been a fan since the 80s, my first use of a Mac was the Mac Plus. I've always had Macs at home. But I've used PCs much more at work and I know when Windows does something better. And it does copying/moving better... MUCH better.

:-Joe
 
I think it is fair to say that Windows Explorer does merging better than Finder. Other copying operations, well, they each have their strong points. If you dig down into the OS underpinnings, however, none of them does merging, the merging is done via application programs in all cases.

At least for me, merging is a rare operation other than synchronizing two computers, and for that I use Chronosync on the Mac.
 
I think it is fair to say that Windows Explorer does merging better than Finder. Other copying operations, well, they each have their strong points. If you dig down into the OS underpinnings, however, none of them does merging, the merging is done via application programs in all cases.

True - but if it were a choice between copying and merging, I prefer the Mac's way. The trouble is, it *isn't* a choice. Windows offers both options via the left click menu. Apple could do the same thing.

At least for me, merging is a rare operation other than synchronizing two computers, and for that I use Chronosync on the Mac.

Me too - but I don't want to set up a Chronosync synchronization for a single merge. And I paid for Chronosync.
 
Yeah... I found this one by the wrong way, just deleted 1.5gb of work for 13mb, just because I thought it was going to merge the 2 folders with the same name. One more for my finder hate list :mad:
 
Yeah... I found this one by the wrong way, just deleted 1.5gb of work for 13mb, just because I thought it was going to merge the 2 folders with the same name. One more for my finder hate list :mad:
:eek: does Undo not work if you do that?

Seriously, people who claim that moving folders and merging is not secure or safe, take heed to the above story! :(
 
:eek: does Undo not work if you do that?(

Nope. You'd better hope you have a backup, because otherwise that data is going to be irretrievable. Even discarding the appropriateness of merge functionality, the way that Finder currently handles folder replacement is dangerous. I simply can't fathom how anyone could consider the existing behavior defensible. The fact that Mac OS has always worked this way is not sufficient reason to allow harmful and inconsistent behavior to persist. It is fallacious to argue that if something has historically worked in a certain manner, then that behavior is necessarily correct.
 
Been a while since I did the vax/vms or Unix stuff LOL. Used to be the only way I accessed the internet at 2400 baud.

I spent a couple of decades with VMS. What it had that made copy/merge very easy and safe, was versioning.

So if I was in a hurry, or just didn't want to be worrying about anything, I could copy an entire directory over to another directory with some of the same-named files in it. VMS would simply bump up the version number for the new files, and keep all the old ones.

Then, later, I could use the PURGE command with appropriate options, such as "keep 2 versions," or "purge everything."

I admit that more than once I did a PURGE that I shouldn't have, and that was bad. Gone meant gone.

I use Chronosync -- makes my life easier.
 
this is truly ridiculous,

anyway for the record i was testing out the Terminal commands and here is what i found:

Code:
mv -n dir1/* dir2

this is the closest thing i found but it is not perfect. the shortcoming is that if there is a directory that is inside both dir1 and dir2 (call it subdir), then items inside subdir or any subsequent subdirectories will not be "merged" or moved in the same way top level items are.

if anyone knows what the Terminal command would be to get this functionality working recursively into all subdirectories, please let me know!

has anyone written an applescript droplet for this? an automator workflow? seems like something i shouldnt have to develop but i might if i can't find it anywhere.

update

this command seems to be what i need on the terminal:

Code:
ditto dir1 dir2

copies files inside dir1 to inside dir2 (overwriting ones that do exist). the caveat is that if the destination (dir2) has newer changes, they will be lost because those files will be replaced by their source (dir1) counterpart.

has anyone written an applescript droplet for this? an automator workflow? seems like something i shouldnt have to develop but i might if i can't find it anywhere.
 
Last edited:
I haven't read the whole thread so I apologise if this has already been mentioned. The way I merge two folders in OSX is to use rsync in Terminal.

Code:
rsync -av folder/ /path/to/other/folder/

This will recursively scan the 2 folders and create a list of differences then fill in all of the gaps for all of the subdirectories.
You got to be careful with the slashes though since

Code:
rsync -av folder /path/to/other/folder/

does something slightly different.

You can read the man pages for rsync for more options, by typing `man rsync` in terminal. It's an amazingly handy and powerful copy command and it's the way most backup apps work I believe.
 
Last edited:
I haven't read the whole thread so I apologise if this has already been mentioned. The way I merge two folders in OSX is to use rsync in Terminal.

Code:
rsync -av folder/ /path/to/other/folder/

This will recursively scan the 2 folders and create a list of differences then fill in all of the gaps for all of the subdirectories.
You got to be careful with the slashes though since

Code:
rsync -av folder /path/to/other/folder/

does something slightly different.

You can read the man pages for rsync for more options, by typing `man rsync` in terminal. It's an amazingly handy and powerful copy command and it's the way most backup apps work I believe.

whats the behavior regarding the timestamps? does it intelligently decide to copy based on which file is newer?

if so, then this method has a +1up on the command i posted, otherwise i think the ditto syntax is simpler.
 
Well with FTP...

Only works on uploading though, I hope this helps someone:

If you use Transmit it has a dialog for replacing or merging folders, it does help when working on websites to be able to merge up.

(Honestly, I only recently noticed the 'Merge' button) :p

Wish it worked on the file local file side too.
 
it makes sense from a unix perspective. it's when you consider it from the perspective of finder where you see the files within the directory, it doesnt make sense that one set would overwrite another. you have to consider it from the level of the top level directory that you're copying onto, the fact that they have the same name means that everything under it will be altered to that of the one you're copying.
 
it makes sense from a unix perspective. it's when you consider it from the perspective of finder where you see the files within the directory, it doesnt make sense that one set would overwrite another. you have to consider it from the level of the top level directory that you're copying onto, the fact that they have the same name means that everything under it will be altered to that of the one you're copying.

Icons are abstractions for our eyes. A "directory" is in fact itself a file. It is a file that lists the names of its contents (and also references their "locations" for programs which can access that info, mainly the OS).

When one drops a file (say some text) into a folder containing a file with the same name... do we expect the contents of those text files to be merged? Why the heck not? (same logic)
 
Icons are abstractions for our eyes. A "directory" is in fact itself a file. It is a file that lists the names of its contents (and also references their "locations" for programs which can access that info, mainly the OS).

When one drops a file (say some text) into a folder containing a file with the same name... do we expect the contents of those text files to be merged? Why the heck not? (same logic)

content-wise you may be right. but the o/s doesn't really know about the innards of files. all it knows is that two files have the same name, and you can't have two of the same name in the same directory on a unix system. the fact that unix directories are files proves the default behavior for os x in that two directories with the same name should overwrite each other by default as it doesn't matter what is contained in them, the fact that they have the same name causes the conflict.
 
I just deleted 150 gb of video from my external hard drive. Tried a bunch of recover methods. Nope, i'm being punished for my stupidity.

Two years late, I was merging my Itunes library that were in 4 different computers and using the NAS to do it, and I ALMOST did the same thing, when I read it, and normally I don't read, I thought this might not work and I am glad that I found this thread, that would have been really upsetting of losing 111 GB worth of Itunes.
 
So all this being said...

Is there a way to recursively merge folders A and B (or even copy A to B) on the Mac in an interactive way where, if there is A/folder_1/file1 and B/folder_1/file1, you get options to:

a) skip
b) keep newer/older copy of file1
c) keep source/destination copy of file1
d) [and this is the kicker] keep BOTH (with one getting an appended filename [probably the new copy of the source version in the destination folder])

with requisite "Apply to all" options?

Cuz at this point it sounds like I should copy both directory structures onto external disks and merge them in Windows, which seems a bit sad.

I mean programmatically it doesn't seem like it would be that complicated--I can kinda see in my head how to do it in pseudocode but I haven't really coded for over a decade so I don't think I'm up to doing it in Applescript/Automator/etc.
 
So all this being said...

Is there a way to recursively merge folders A and B (or even copy A to B) on the Mac in an interactive way where, if there is A/folder_1/file1 and B/folder_1/file1, you get options to:

a) skip
b) keep newer/older copy of file1
c) keep source/destination copy of file1
d) [and this is the kicker] keep BOTH (with one getting an appended filename [probably the new copy of the source version in the destination folder])

with requisite "Apply to all" options?

Cuz at this point it sounds like I should copy both directory structures onto external disks and merge them in Windows, which seems a bit sad.

I mean programmatically it doesn't seem like it would be that complicated--I can kinda see in my head how to do it in pseudocode but I haven't really coded for over a decade so I don't think I'm up to doing it in Applescript/Automator/etc.

I think the rsync command can do all of this.

look at http://www.samba.org/ftp/rsync/rsync.html

-b, --backup
With this option, preexisting destination files are renamed as each file is transferred or deleted. You can control where the backup file goes and what (if any) suffix gets appended using the --backup-dir and --suffix options.
-u, --update
This forces rsync to skip any files which exist on the destination and have a modified time that is newer than the source file. (If an existing destination file has a modification time equal to the source file's, it will be updated if the sizes are different.)

I would do something like
rsync -avub folder/ destination/
 
This suggestion posted earlier in this thread works for me:



it will recursively go through folders to synchronise. There are various options, but easiest is reciprocal sync; so if have two folders A and B, then sync A & B will ensure that any unique file will be copied in the other, and older files overwritten by newer. It has 'simulation' mode, so you can see what it would do without actually executing. Then when A & B are in sync, you can delete one of these fully duplicated folders. End result: folder contents are merged.

Limitation of this is it doesn't seem to do chronological versioning - i.e. have option keep both older and newer versions - like Chronosync - but SyncTwoFolders is Free, easy, and may suit some better than rsync, terminal commands etc.
 
I think the rsync command can do all of this.

look at http://www.samba.org/ftp/rsync/rsync.html

I would do something like
rsync -avub folder/ destination/
So far this is doing okay (although I'm not using the -b option) but if you try to merge folderB into folderA and then merge folderC into folderA and there's already a backed-up file (i.e. if folderA and folderB had a file in them named "file1", you now have file1 and file1~ in folderA), it gets overwritten unless you specify a new suffix on the second rsync (i.e. instead of ending up with three copies of file1, the file1~ copy gets overwritten). Also, obviously rsync is not interactive so there's no way to catch this on the fly.
 
Status
Not open for further replies.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.