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

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