Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Copying folder: Macs vs. Windows vs. UNIX System
Credit where credit is due ... this is based on following this thread in the Forums, but I thought it would be of general interest. First of all, a WARNING to Windows users new to Macs:

In Windows, dragging a folder to a destination where a folder with the same name already exists results in the contents of the source folder being added to the contents of the pre-existing folder. If a file with the same name exists within both folders, then the version in the destination folder will be replaced, but otherwise, the contents of the pre-existing folder remain intact.

On Macs, although you will be warned first, the pre-existing folder as an entity will be replaced by the source folder. If you are not familiar with the traditional Mac behaviour, DATA WILL BE LOST. (If you immediately realize your mistake, OS X Finder can 'undo' this). According to the original poster (rozeel) in the thread, Finder is the oddball in this case, and Windows and Unix follow the merging behaviour.

This won't be news to a Unix user, but for a long time Mac-user but Unix dummy like myself, learning of the existence of a way to effectively merge different versions of a folder was a 'wow' moment. Read the rest of the hint to see a quick Terminal command to merge two folders together...

Given a source folder:
~/FolderX (containing files 1.txt, 2.txt, 3.txt)
... and a destination folder:
~/EnclosingFolder/FolderX (containing files a.txt b.txt c.txt)
Then the Terminal command:
cp -R ~/FolderX ~/EnclosingFolder
results in ~/EnclosingFolder/FolderX containing files 1.txt, 2.txt, 3.txt, a.txt, b.txt, and c.txt. The contents of the two folders are merged.

Some Notes: If you add an extra slash at the end of ~/FolderX/, then the contents of FolderX will be added to EnclosingFolder at the same level as FolderX, the result being more of an addition, not a merge. This works with CpMac -r as well. However, there are differences with cp when variations of the above syntax are used. If the two 'FolderX's both contain subfolders sharing common names, the merging occurs recursively within them as well, which is where this command becomes really useful.

[robg adds: This is a fundamental difference between UNIX, Mac, and Windows -- of the three, only the Mac uses the "replace" functionality, which can definitely catch a switcher by surprise. I know I'm always surprised the other direction on my Windows box at work -- 'hey, how come those files weren't erased by my copied folder?' Also a caution, though -- if you're not careful with cp -R, you can quickly find yourself doing more than you expected, and might lose something important in the process. Please back up regularly!]
    •    
  • Currently 1.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (1 vote cast)
 
[12,547 views]  

Copying folder: Macs vs. Windows vs. UNIX | 12 comments | Create New Account
Click here to return to the 'Copying folder: Macs vs. Windows vs. UNIX' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Copying folder: Macs vs. Windows vs. UNIX
Authored by: rammjet on Apr 14, '04 11:52:36AM

The typical Mac way to merge two folders is to:

a) open the source folder
b) select all of the contents (Command-A, Edit menu->Select All, or drag-select the files)
c) drag and drop those onto the target folder (either open or closed).

Not hard really and MacOS X is more graceful (vs Mac Classic) in the way it handles files with the same names.



[ Reply to This | # ]
Copying folder: Macs vs. Windows vs. UNIX
Authored by: deleted_user18 on Apr 14, '04 12:08:04PM

Yes but what is if both folders have subfolders? I will then have to this over and over again for every subfolder or I will loose data.

Strange behaviour...



[ Reply to This | # ]
Copying folder: Macs vs. Windows vs. UNIX
Authored by: Tulse on Apr 14, '04 12:15:29PM

I actually think the Mac behaviour makes sense, or is at least more consistent with the way the rest of the file management system works. If you move a file into a folder with a file of the same name, you are prompted, and the file gets replaced. Folders work the same way. That seems straightforward to me. There will, I suppose, be occasions when one intentionally has two folders in different locations that have the same name and mergeable content, but my guess is that those situation will be far less common than one where someone has mistakenly given the same name to two folders.



[ Reply to This | # ]
Copying folder: Macs vs. Windows vs. UNIX
Authored by: SOX on Apr 14, '04 12:02:59PM

Huh? the poster must be confused. In unix if you copy a folder with the same name into a folder with a pre-existing folder with the same name it overwrites. it does not merge.



[ Reply to This | # ]
cp and rsrc forks
Authored by: JohnnyMnemonic on Apr 14, '04 12:17:28PM

Be careful with "cp"--it will not move Resource forks, which, depending on the Application and depending on the file--are still used.

CpMac will preserve Resource forks, but is only present after a Developer Tool install.

I'd be interested to hear from folks which apps still want to have their resource fork preserved, as I haven't investigated it much. Is is just Classic Apps?



[ Reply to This | # ]
cp and rsrc forks
Authored by: inik on Apr 14, '04 01:28:01PM

"cp --rsrc [source] [destination]" will handle resource forks. It's undocumented, but it works.



[ Reply to This | # ]
ditto
Authored by: Graff on Apr 14, '04 01:57:31PM

Use ditto instead. It's part of the default install and it handles resource forks and metadata. You use the --rsrc flag to tell it to handle the resource forks and metadata. In this hint you would replace the line:

cp -R ~/FolderX ~/EnclosingFolder

with

ditto --rsrc ~/FolderX ~/EnclosingFolder



[ Reply to This | # ]
cp and rsrc forks
Authored by: Crimson Napkin on Apr 14, '04 02:11:50PM

I had never heard that you could use -rsrc with cp (with ditto, yes, but cp...hmmm).

Use cp for files that don't have resource forks or metadata. Use CpMac (comes with the Developer Tools) for things that have these. For me, this means copy photos with CpMac in order to preserve the image metadata.

You can also use these to copy huge files to other machines on your network. It is faster to copy with cp or CpMac than it is to drag and drop. For example, you have a giant CAD project that needs to go to your bosses machine. Use CpMac to copy it to a network accesible directory on his machine and the file will copy faster than drag and drop.

---
macosxhints.com is one reason PC users should switch to a Mac.

[ Reply to This | # ]

cp -R and rsrc forks
Authored by: googoo on Apr 14, '04 02:49:24PM

cp does not copy resource forks, but cp -R seems to do so! Maybe it works because the resource fork looks like a file in a subdirectory. For example if the filename is file1, its resource fork is file1/rsrc. Try using

% ls file1/rsrc

on a file that you know has a resource fork. Now try

% cp -R file1 another/location

Go to another/location and list its resource fork. It is there!

-Mark

[ Reply to This | # ]

Unix Guru Says: Use xtar
Authored by: forman on Apr 14, '04 07:08:09PM

By default "cp" will follow or dereference symbolic links. That is, a "cp -R" will copy the file that the link points to instead of the link. Some versions of "cp" allow the "-d" or "--no-dereference" flag to prevent this, however I got in the habit of using "tar" instead years ago:

To copy a directory I simply do this:

tar cvf - directory/ | (cd /new/location; tar xvf - )

"cvf -" means compress the directory verbosely into the file called - (standard out). The standard out is then piped ("|") into a compound command surrounded by parentheses, which first changes directories and then extracts data from standard in ("-").

What's interesting is, now that Unix and MacOS have merged, the same problem exists with resource forks being omitted by "cp -R". Thus to recursively copy a directory, preserving all links and resource forks, one can use the above command, substituting "xtar" for "tar".

To copy directories between machines, this command is exceptionally useful (substitute "xtar" if resource forks are present):

tar cvf - directory/ | ssh user@host '(cd /some/path; tar xvf - )'

Instead of all those GUI "ssh" programs, I run this from the command line daily to move files between different machines.

Michael.

[ Reply to This | # ]
Minor nit [Re: Unix Guru Says: Use xtar]
Authored by: ubi on Apr 15, '04 11:26:03PM

The -c option of tar doesn't stand for Compress, but rather for Create. Normally, tar is used for lisTing the contents of (-t), eXtracting from (-x), or Creating (-X) a tar (Tape ARchive) file. The compression flags are -z for gZip or -j for bzip2 (go figure).



[ Reply to This | # ]
Be safe!
Authored by: sn00py on Apr 14, '04 11:15:31PM

To be safe, always use -i. Whatever other option you use, you can always
stick this in there.

cp -i -R ....

Then it will ask you if you want to overwrite a file with the same name.



[ Reply to This | # ]