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"

Reply via email to