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

26.03.2012 03:25, Tim Kientzle пишет:
> 
> 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?

zfs

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