Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 20 Oct 2008 21:14:48 -0700
From:      Tim Kientzle <kientzle@freebsd.org>
To:        "Carlos A. M. dos Santos" <unixmania@gmail.com>
Cc:        freebsd-current@freebsd.org
Subject:   Re: Problem extracting Zip file
Message-ID:  <48FD5738.60401@freebsd.org>
In-Reply-To: <e71790db0810141514u83484d0s60d61b81a233bcad@mail.gmail.com>
References:  <e71790db0810141514u83484d0s60d61b81a233bcad@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------000803090807050403030005
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Carlos A. M. dos Santos wrote:
> 
> % fetch http://movies.apple.com/movies/us/apple/mac/macbook/2008/designvideo/apple_new_macbook_video_20081014_848x480.zip
> % unzip -l apple_new_macbook_video_20081014_848x480.zip
> Archive:  apple_new_macbook_video_20081014_848x480.zip
>   Length     Date   Time    Name
>  --------    ----   ----    ----
> 153902587  10-14-08 11:46   apple_new_macbook_video_20081014_848x480.mov
>         0  10-14-08 11:48   __MACOSX/
>        82  10-14-08 11:46
> __MACOSX/._apple_new_macbook_video_20081014_848x480.mov
> 
> Observe that the archive contains two instances of the .mov file but
> the second one, according to unzip, is only 82 bytes long.

The second file here is actually the Mac OS "resource fork."

> % tar xf apple_new_macbook_video_20081014_848x480.zip
> apple_new_macbook_video_20081014_848x480.mov: Attempt to write to an empty file
> __MACOSX/._apple_new_macbook_video_20081014_848x480.mov: Attempt to
> write to an empty file
> tar: Error exit delayed from previous errors.

Ouch.  I know what this is.  I recently taught libarchive
to distinguish "file has zero size" from "the file size is
unknown" in a lot of cases, but apparently I missed this one.
The "unknown size" stored in the Zip header here is getting
incorrectly treated as a zero size.

Please try the attached patch which fixes the Zip reader
in libarchive to leave the file size "unknown" in
this case.  Let me know if it fixes the issue for you.

Cheers,

Tim

--------------000803090807050403030005
Content-Type: text/x-patch;
 name="libarchive_zip_length_at_end_fix.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="libarchive_zip_length_at_end_fix.patch"

Index: archive_read_support_format_zip.c
===================================================================
--- archive_read_support_format_zip.c	(revision 184037)
+++ archive_read_support_format_zip.c	(working copy)
@@ -444,7 +444,9 @@
 	archive_entry_set_mtime(entry, zip->mtime, 0);
 	archive_entry_set_ctime(entry, zip->ctime, 0);
 	archive_entry_set_atime(entry, zip->atime, 0);
-	archive_entry_set_size(entry, zip->uncompressed_size);
+	/* Set the size but only if it's meaningful. */
+	if (0 == (zip->flags & ZIP_LENGTH_AT_END))
+		archive_entry_set_size(entry, zip->uncompressed_size);
 
 	zip->entry_bytes_remaining = zip->compressed_size;
 	zip->entry_offset = 0;

--------------000803090807050403030005--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48FD5738.60401>