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

25.03.2012 21:53, Tim Kientzle пишет:
> 
> 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?

I used misc/mc to walk through the filesystem of the tar archive
and then just copy <F5> the library to an existing file system.

OK, you are right. Seems that mc has made a joke on me. When
I extract the file at command line it consists of zeros:
-----
% tar xvf /tmp/test.tar --strip-components 16
% ls -l
total 1
-rwxr-xr-x  1 bsam  wheel  241971 24 мар 08:48 libnspr4.so.1
% hd libnspr4.so.1
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
|................|
*
0003b130
-----

>   * 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.

Interesting... I'll create three tar archives (without truss,
with truss and with kdump):
-----
% ls -l /tmp/test/
total 0
% sudo tar -cvf /tmp/test/no-truss.tar
/usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1
[...]
% sudo truss tar -cvf /tmp/test/truss.tar
/usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1
[...]
% sudo ktrace tar -cvf /tmp/test/ktrace.tar
/usr/ports/devel/nspr/work/nspr-4.9/mozilla/nsprpub/build/dist/lib/../../pr/src/./libnspr4.so.1
% ls -l /tmp/test
total 248
-rw-r--r--  1 root  wheel    3072 25 мар 22:47 ktrace.tar
-rw-r--r--  1 root  wheel    3072 25 мар 22:46 no-truss.tar
-rw-r--r--  1 root  wheel  243712 25 мар 22:47 truss.tar
-----

Seems that we get a good tar archive while using truss!

Lets see what kdump says. The relevant last part is attached.

> I'll spend some time today to see if I can reproduce the problem here.

Thanks. Let me know if I can help you here.

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve