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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:36 UTC