Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

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

Report information
The Basics
Id:
34657
Status:
new
Priority:
Low/Low
Queue:

People
Owner:
Nobody in particular
Requestors:
jerry [...] ieee.org
Cc:
AdminCc:

BugTracker
Severity:
Normal
Broken in:
1.23
Fixed in:
(no value)



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.


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.