Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have a number of directories, they're all demos of web scripts I have created, the important fact is they all share resources. So I have created a global resources directory and symbolically linked that directory into each of the demo folders.

What I want to do is compress each demo directory into a .zip file, the problem I have is the symbolic links are maintained in the zip file and on another machine the resource directory simply wouldn't exist.

Is there a way to zip a demo folder up with any symbolic links resolved so when unzipped the files appear as if they were part of the standard file structure?

Many thanks :-)

share|improve this question

3 Answers 3

This is the default behavior for Info-ZIP's zip. You need to pass -y or --symlinks in order to store symlinks within the archive instead.

share|improve this answer

Zip help reads:

-y store symbolic links as the link instead of the referenced file

share|improve this answer
    
Thanks for your answer, when I run the following command zip -r -y demo.zip demo/ the symlink appear as a file, not a directory. The file has no icon or file type either :S –  Ben Everard Dec 15 '10 at 23:38
1  
@ILMV: Isn't -y the exact opposite of what you want to accomplish? –  Daniel Beck Dec 16 '10 at 2:06

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:

alt text

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:

alt text

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.