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 _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"