On Tue, Oct 21, 2008 at 2:14 AM, Tim Kientzle <kientzle_at_freebsd.org> wrote: > 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 > I tested with your recent commit to libarchive (r184109) and it works. Thanks. -- cd /usr/ports/sysutils/life make cleanReceived on Tue Oct 21 2008 - 22:30:02 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:36 UTC