Bug 153665

Summary: Unzip does not handle deferred symbolic links in NFS filesystem
Product: [Fedora] Fedora Reporter: Aaron Gaudio <madcap>
Component: unzipAssignee: Ivana Varekova <varekova>
Status: CLOSED UPSTREAM QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 4   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-04-12 14:04:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Test case with 1 deferred and 1 unresolved symlink. none

Description Aaron Gaudio 2005-04-04 20:19:24 UTC
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.

Comment 1 Aaron Gaudio 2005-04-04 20:19:25 UTC
Created attachment 112683 [details]
Test case with 1 deferred and 1 unresolved symlink.

Comment 2 Ivana Varekova 2005-04-05 14:34:24 UTC
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-06 00:46:30 UTC
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

Comment 4 Ivana Varekova 2005-04-06 07:50:26 UTC
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

Comment 5 Aaron Gaudio 2005-04-06 13:47:37 UTC
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.

Comment 6 Ivana Varekova 2005-04-07 08:29:43 UTC
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