/usr/bin/tar creates invalid lib file
Tim Kientzle
tim at kientzle.com
Sun Mar 25 17:53:25 UTC 2012
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
More information about the freebsd-current
mailing list