Bug 153665 - Unzip does not handle deferred symbolic links in NFS filesystem
Unzip does not handle deferred symbolic links in NFS filesystem
Product: Fedora
Classification: Fedora
Component: unzip (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ivana Varekova
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2005-04-04 16:19 EDT by Aaron Gaudio
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-12 10:04:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Test case with 1 deferred and 1 unresolved symlink. (382 bytes, application/octet-stream)
2005-04-04 16:19 EDT, Aaron Gaudio
no flags Details

  None (edit)
Description Aaron Gaudio 2005-04-04 16:19:24 EDT
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):

How reproducible:

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

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.
Comment 1 Aaron Gaudio 2005-04-04 16:19:25 EDT
Created attachment 112683 [details]
Test case with 1 deferred and 1 unresolved symlink.
Comment 2 Ivana Varekova 2005-04-05 10:34:24 EDT
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
Comment 3 Aaron Gaudio 2005-04-05 20:46:30 EDT
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
total 0
-r--------  1 agaudio mc-csp 0 Apr  5 20:42 b
-r--------  1 agaudio mc-csp 0 Apr  5 20:42 c
Comment 4 Ivana Varekova 2005-04-06 03:50:26 EDT
I try to reproduce your problem on NFS-mounted filesystem, but unzip was right
again. Have you got enough space to create nonempty file?
Comment 5 Aaron Gaudio 2005-04-06 09:47:37 EDT

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
Comment 6 Ivana Varekova 2005-04-07 04:29:43 EDT
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.
Thank you.

Note You need to log in before you can comment on or make changes to this bug.