On Aug 7, 2011, at 9:23 AM, Bruce Cran wrote: > On 06/08/2011 18:02, Martin Matuska wrote: >> The error is in FreeBSD ISO images. >> They are created using makefs and that doesn't create ISO files that >> strictly comple to the ECMA-119 (ISO9660 standard). >> >> I have already filed a PR at NetBSD (bin/45217): >> http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=45217 >> >> The volume_set_id doesn't have to be filled with 0x20 characters, too. >> I am also preparing a patch for libarchive (different things), but that >> won't fix that one bug - makefs needs to be fixed. > > Thanks for the information - I suspect this is also the problem I saw a few > weeks ago on OS X Lion when trying to extract an ISO of Windows Server 2003 > R2: > > neutrino:tmp brucec$ tar -xvf > en_win_srv_2003_r2_standard_with_sp2_cd2_X13-68583.iso > neutrino:tmp brucec$ echo $? > 0 > > It would be nice if bsdtar exited with a non-zero code in this case.
I agree, it would be nice. ISO images frequently begin with a large block of zero bytes that looks exactly like a tar end-of-file marker. So if libarchive doesn't recognize it as an ISO, it will often recognize the file as a valid empty tar archive that has a bunch of garbage after the end-of-archive marker. So it successfully extracts no files. This sort of problem should become less common as we continue to refine the bidding heuristics used in libarchive. If you have ideas for further improving them, I'm definitely interested. (At a minimum, I'm always interested in seeing at least the first 32k or so of any file that "tar -tvvvf" gives the wrong format for.) Tim _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
