Date: Sun, 25 Mar 2012 10:53:16 -0700 From: Tim Kientzle <tim@kientzle.com> To: Boris Samorodov <bsam@passap.ru> Cc: freebsd-current@freebsd.org, Dimitry Andric <dim@freebsd.org> Subject: Re: /usr/bin/tar creates invalid lib file Message-ID: <38D08B05-58E1-4266-9628-2C22836806D3@kientzle.com> In-Reply-To: <4F6F155E.30902@passap.ru> References: <4F6CD93D.70109@passap.ru> <4F6CEB1F.4040300@FreeBSD.org> <4F6D52DF.7080105@passap.ru> <4F34E618-DB66-464D-B5B2-900960D6C16B@kientzle.com> <4F6F155E.30902@passap.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 25, 2012, at 5:53 AM, Boris Samorodov wrote: > On 24.03.2012 21:00, Tim Kientzle wrote: >>=20 >> On Mar 23, 2012, at 9:51 PM, Boris Samorodov wrote: >>=20 >> Can you send me the output of: >>=20 >> tar -cvf /tmp/test.tar = /usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../p= r/src/./libnspr4.so.1 >>=20 >> (A tar archive containing only that one source file.) >>=20 >> 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=85. if it did, it will be obvious from the structure of the >> created archive. >=20 > 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 > ----- >=20 > 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. There are a lot of things here that don't make sense: * The extracted file should be all zero bytes. (The 2.0.0.241971.0. = is the sparse file map, it's not really part of the file.) How are you = extracting this? * Can you run the tar command under truss or ktrace and look for calls = to lseek()? That would help verify that this is really a tar bug and = not a filesystem or kernel bug. I'll spend some time today to see if I can reproduce the problem here. Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38D08B05-58E1-4266-9628-2C22836806D3>