Re: /usr/bin/tar creates invalid lib file

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.

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