cp -R .app directory

[DeepBlade]

How come when you copy an application from one location to another using cp -R on the .app "directory", the size and the contents change?

I understand that the .app "directory" is not just a simple directory, so I was wondering if someone could give more details?

 

[r0k]

How come when you copy an application from one location to another using cp -R on the .app "directory", the size and the contents change?

I understand that the .app "directory" is not just a simple directory, so I was wondering if someone could give more details?

The unix cp command is somewhat lazy. It sees a sym link and does not copy the link but rather makes a new copy of whatever file was linked and names it the same as the sym link. On first glance, everything looks OK, but closer examination reveals what were links before CP are now files.

Whenever I run cp -R and wind up with differing sizes, I check for symbolic links that have been converted to copies. I have not noticed a situation where the destination of a cp command gets smaller unless I didn't have read permission on some of the files I was trying to copy.

A more robust method of copying is to use

tar cf - * | ( cd /target; tar xfp -)
( I haven't used this in years, but basically you are creating a tarball and piping it to a command to untar it at the new destination.) more here...

tar is a lot smarter than cp and links remain links.

 

[belvdr]

The unix cp command is somewhat lazy. It sees a sym link and does not copy the link but rather makes a new copy of whatever file was linked and names it the same as the sym link. On first glance, everything looks OK, but closer examination reveals what were links before CP are now files.

Whenever I run cp -R and wind up with differing sizes, I check for symbolic links that have been converted to copies. I have not noticed a situation where the destination of a cp command gets smaller unless I didn't have read permission on some of the files I was trying to copy.

A more robust method of copying is to use

tar czvf - | tar xzvf
(sorry I don't remember the exact syntax b/c I haven't used this in years, but basically you are creating a tarball and piping it to a command to untar it at the new destination.) more here...

tar is a lot smarter than cp and links remain links.

Agreed. Later versions of cp include the option -d to preserve links. OP, you should see if your version of cp has this.

 

[DeepBlade]

Huh.. Very interesting replies. Thanks guys! I didn't know there could potentially be symlink problems when copying.

I actually found out my specific problem though:

When I'm copying it to a Windows share, Windows doesn't like the fact that file paths are so long, so it starts chopping away stuff that's in paths that are too long.

http://www.codinghorror.com/blog/2006/11/filesystem-paths-how-long-is-too-long.html