Skip Menu |

This queue is for tickets about the Archive-Zip CPAN distribution.

Report information
The Basics
Id: 34657
Status: new
Priority: 0/
Queue: Archive-Zip

Owner: Nobody in particular
Requestors: jerry [...]

Bug Information
Severity: Normal
Broken in: 1.23
Fixed in: (no value)

Subject: No option, undefined behavior zipping symbolic links (symlinks)
Download (untitled) / with headers
text/plain 1.2k
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.

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to