Red Hat Bugzilla – Bug 153665
Unzip does not handle deferred symbolic links in NFS filesystem
Last modified: 2007-11-30 17:11:03 EST
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):
Steps to Reproduce:
1. Download the attached test case "foo.zip".
2. Attempt to unzip it to a temporary directory.
foo/b and foo/c are created as empty files with warning "warning: symbolic link
foo/b should be a symlink to "../b".
foo/c should be a (broken) symlink to non-existent file "../c".
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
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.
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
linking: foo/b warning: symbolic link (foo/b) failed
linking: foo/c warning: symbolic link (foo/c) failed
$ ls -lR foo
-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?
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
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
You can reproduce this bug so if there will be necessary some other
specifications you can answer it directly.