| 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.