Description of problem: Previous versions of unzip would crash when encountering a symbolic link which does not resolve (because the target has not been unpacked from the archive yet). The latest rawhide version doesn't crash, but it does not handle such symlinks correctly (see expected behavior below). Version-Release number of selected component (if applicable): unzip-5.51-10 How reproducible: Always Steps to Reproduce: 1. Download the attached test case "foo.zip". 2. Attempt to unzip it to a temporary directory. Actual results: foo/b and foo/c are created as empty files with warning "warning: symbolic link (foo/c) failed". Expected results: foo/b should be a symlink to "../b". foo/c should be a (broken) symlink to non-existent file "../c". Additional info: This works as expected in Solaris unzip (version 5.12). Note that the symlink has to be extracted before its target (if there is one) to reproduce this bug. The easiest way to force this is to put the symlink in a sub-directory. Red Hat bugzilla #134073 touches on this issue. In previous releases of unzip 5.51, unzip would segfault in these scenarios. Now it just creates empty files.
Created attachment 112683 [details] Test case with 1 deferred and 1 unresolved symlink.
I try to reproduce this problem, but I can't reproduce it. My unzip works right. Can you write me sizes of unpacked files foo/b and foo/c. Ivana Varekova
You're right... after testing again, this works from a normal filesystem. However, when I run this from an NFS-mounted filesystem, that's when I get the error. I confirmed that Solaris's unzip behaves correctly even over NFS. I've updated the summary appropriately. Example output follows: $ unzip /tmp/foo.zip Archive: /tmp/foo.zip extracting: b linking: foo/b warning: symbolic link (foo/b) failed linking: foo/c warning: symbolic link (foo/c) failed $ ls -lR foo foo: total 0 -r-------- 1 agaudio mc-csp 0 Apr 5 20:42 b -r-------- 1 agaudio mc-csp 0 Apr 5 20:42 c
I try to reproduce your problem on NFS-mounted filesystem, but unzip was right again. Have you got enough space to create nonempty file? Ivana
Ivana, Thanks for your diligence on this. I've narrowed it down further. The problem apparently only happens on a Solaris-exported NFS filesystems. There is plenty of space on the drive. I've tried it with Solaris 8 NFS and Solaris 10 NFS with no luck. Note that I am able to create symlinks manually using 'ln -s' on such filesystems.
Aaron, thank you for the bug report. However this bug should be reported upstream (and fixed by unzip developers). Can you please report this bug to upstream (http://www.goatley.com/hunter/zip-bug.html)? You can reproduce this bug so if there will be necessary some other specifications you can answer it directly. Thank you. Ivana