|Subject:||No option, undefined behavior zipping symbolic links (symlinks)|
This bug is the "converse" of bug 22933. Short explanation: addTree() needs an option similar to the -y option in the bash shell version of zip (see man zip) for symbolic links (also called symlinks). Documentation states that "this will not follow symbolic links to directories". RESULT: When symbolic link to a directory is zipped by Archive::Zip and then later unzipped by zip in bash, it is an empty directory. So, indeed it does not "follow" it, but it does not give the useful result, which would be to reproduce the same symbolic link that existed in the input. Documentation makes no explanation of what happens when symbolic links to regular files are zipped. RESULT: When symbolic link to a regular file is zipped by Archive::Zip and then later unzipped by zip in bash, it is found to be the "original" or "target" file that the symlink pointed to. In other words, Archive::Zip "follows" the symbolic link when creating the archive. I'm not sure how widespread the need for this option is, but I needed this feature when attempting to zip an application package containing "frameworks" in Mac OS X. Mac OS X frameworks each contain several symbolic links to other files or directories which are buried deeper in the directory.