Couple of questions:1) Does the folder structure you are archiving use symbolic links internally to save on space? (By "internally", I mean, given a particular root folder, do the symbolic links within that root folder only refer to other files or directories that are also within that folder?).
2) How are you creating the .zip archive in OS X? (Using a command-line tool, and if so, which one, or by using Archive Utility, etc.)
3) What operating system is the target computer (where the archive will be unzipped) running, and what method are you using to unzip the file there?
First of all, in OS X, symbolic links are basically plain text files with some extra "Mac" information that lets OS X know that it should treat the file as a symbolic link. This extra Mac information is a special file type, creator code, and Finder flag information, which is stored not in the file itself, but in the HFS+ disk directory.
In OS X, when you create a .zip file, there is no room in the zip stream for this extra Mac information, so, in a sense, the symbolic link is stored within the zip file as a plain file. Whether someone on another Mac can unzip the archive and have it properly represent the original structure appears to depend on who or what you use to unzip it.
For example, a month or so ago a company released a game over Steam, Valve's game distribution software. The game application bundle included NVIDIA's Cg library in the form of a framework, which internally use symbolic links. There was originally a problem with Steam not properly restoring the necessary Mac information on Trine.app as mentioned in this thread:http://forums.steampowered.com/forums/showthread.php?t=1556083
The image below shows 2 different copies of the Cg.framework, one I had installed separately from NVIDIA's website (upper image), and the lower image shows what was received with the game:
Notice that all the items match up, but what should be symbolic links are plain data files.
After taking a closer look at the FSCatalogInfo record for both the items, it was clear to me what the issue was:
You'll notice in the upper image that the beginning of the finderInfo struct has the following values:
0x736C6E6B = 'slnk'0x72686170 = 'rhap'These values are defined in /usr/include/hfs/hfs_format.h:
/* * File type and creator for symbolic links*/enum { kSymLinkFileType = 0x736C6E6B, /* 'slnk' */ kSymLinkCreator = 0x72686170 /* 'rhap' */};The 9th byte value, 0x80, corresponds to the kIsAlias flag of the finderInfo.finderFlags. That value is defined in /System/Library/Frameworks/CoreServices.framework/.../CarbonCore.framework/.../Headers/Finder.h:
enum { kIsAlias = 0x8000 /* Files only */};It appears that unzip feature built-in to OS X (Archive Utility) is hard-coded to look for possible files in the archive that's being unzipped that represent symbolic links, and to set the information appropriately. I believe that /usr/bin/ditto (when used for its ability to archive files) also takes care of this for you. I'm not sure whether zip or unzip do.