Date: Mon, 26 Mar 2012 00:43:27 +0300 From: Gleb Kurtsou <gleb.kurtsou@gmail.com> To: Tim Kientzle <tim@kientzle.com> Cc: Dimitry Andric <dim@freebsd.org>, freebsd-current@freebsd.org, Boris Samorodov <bsam@passap.ru> Subject: Re: /usr/bin/tar creates invalid lib file Message-ID: <20120325214327.GA1238@reks> In-Reply-To: <38D08B05-58E1-4266-9628-2C22836806D3@kientzle.com> References: <4F6CD93D.70109@passap.ru> <4F6CEB1F.4040300@FreeBSD.org> <4F6D52DF.7080105@passap.ru> <4F34E618-DB66-464D-B5B2-900960D6C16B@kientzle.com> <4F6F155E.30902@passap.ru> <38D08B05-58E1-4266-9628-2C22836806D3@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
I run stacked file system (PEFS) on top of ZFS. ZFS reports
_PC_MIN_HOLE_SIZE, but ioctls to lower level fs disabled are in PEFS.
I work around it by properly handling _PC_MIN_HOLE_SIZE.
Test case:
% for i in a b c; do echo $i > $i; done
% tar cf 1.tar a b c
tar: lseek(SEEK_HOLE) failed: Inappropriate ioctl for device
tar: lseek(SEEK_HOLE) failed: Inappropriate ioctl for device
tar: lseek(SEEK_HOLE) failed: Inappropriate ioctl for device
% ls -l 1.tar
-rw-r--r-- 1 gleb gleb 1024 Mar 26 00:28 1.tar
% tar tf 1.tar # <-- no files in archive
%
truss log:
__acl_get_link(0x801c8c100,0x2,0x801d82000,0x0,0x1000,0x0) ERR#22 'Invalid argument'
extattr_list_link(0x801c8c100,0x1,0x0,0x0,0x7fffffffc530,0x0) ERR#45 'Operation not supported'
pathconf("a",0x15) = 512 (0x200)
open("a",O_NONBLOCK,037777751270) = 5 (0x5)
lseek(5,0x0,0x3) ERR#25 'Inappropriate ioctl for device'
close(5) = 0 (0x0)
tar: write(2,"tar: ",5) = 5 (0x5)
Thanks,
Gleb.
>
> 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-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120325214327.GA1238>