Date: Sun, 25 Mar 2012 16:25:05 -0700 From: Tim Kientzle <tim@kientzle.com> To: Gleb Kurtsou <gleb.kurtsou@gmail.com> Cc: Dimitry Andric <dim@freebsd.org>, freebsd-current@freebsd.org, Boris Samorodov <bsam@passap.ru> Subject: Re: /usr/bin/tar creates invalid lib file Message-ID: <C932776E-F988-46DB-B024-19C8C5B61301@kientzle.com> In-Reply-To: <20120325214327.GA1238@reks> References: <4F6CD93D.70109@passap.ru> <4F6CEB1F.4040300@FreeBSD.org> <4F6D52DF.7080105@passap.ru> <4F34E618-DB66-464D-B5B2-900960D6C16B@kientzle.com> <4F6F155E.30902@passap.ru> <38D08B05-58E1-4266-9628-2C22836806D3@kientzle.com> <20120325214327.GA1238@reks>
index | next in thread | previous in thread | raw e-mail
On Mar 25, 2012, at 2:43 PM, Gleb Kurtsou wrote: > On (25/03/2012 10:53), Tim Kientzle wrote: >> >> On Mar 25, 2012, at 5:53 AM, Boris Samorodov wrote: >> >>> On 24.03.2012 21:00, Tim Kientzle wrote: >>>> >>>> On Mar 23, 2012, at 9:51 PM, Boris Samorodov wrote: >>>> >>>> Can you send me the output of: >>>> >>>> tar -cvf /tmp/test.tar /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1 >>>> >>>> (A tar archive containing only that one source file.) >>>> >>>> This looks similar to a bug that we found in libarchive recently >>>> I didn't think that bug impacted FreeBSD, but I may have been >>>> wrong…. if it did, it will be obvious from the structure of the >>>> created archive. >>> >>> The following file is extracted after tarring: >>> ----- >>> % hd libnspr4.so.1 >>> 00000000 32 0a 30 0a 30 0a 32 34 31 39 37 31 0a 30 0a 00 |2.0.0.241971.0..| >>> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| >>> * >>> 00000200 >>> ----- >>> >>> The tar file itself attached (3KB in length). >> >> Ugh. I'll probably need your help to diagnose this more precisely. >> >> Here is the root problem: tar thinks this is a sparse file >> with nothing in it. On FreeBSD, bsdtar now uses >> lseek(SEEK_HOLE) to identify holes in the file. For >> some reason, bsdtar is storing this file as just one big hole. > > I experience a related issue. lseek(SEEK_HOLE) error checks are too > strict. Files are not added to archive if lseek(SEEK_HOLE) fails. > Ignoring lseek(SEEK_HOLE) at least in ENOTTY case would be preferable. This has already been fixed upstream. I'll get the fix merged soon… Boris: What filesystem are you using? Timhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C932776E-F988-46DB-B024-19C8C5B61301>