bin/106973: tar(1) cannot read own tape, but pax(1) can

[Bernd Luevelsmeyer]

The following reply was made to PR bin/106973; it has been noted by GNATS.

From: Bernd Luevelsmeyer <bdluevel at heitec.net>
To: bug-followup at FreeBSD.org
Cc: Tim Kientzle <kientzle at freebsd.org>
Subject: Re: bin/106973: tar(1) cannot read own tape, but pax(1) can
Date: Wed, 11 Jul 2007 10:36:49 +0200

 This issue came up in the freebsd-stable mailing list. Tim Kientzle
 wrote in <46679117.5060909 at freebsd.org> that the SCSI tape driver in 6.2
 claims to be able to do lseek() while in fact it cannot. tar believes it
 and issues lseek() commands, whereupon things go bad. (Apparently, pax
 simply doesn't use lseek() commands, hence has no problems.)
 
 In <4675CD95.9040004 at freebsd.org>, he published a patch that prevents
 tar from using lseek() commands. With this patch, tar works just fine
 for me again. However, IMHO this is only a workaround; really, the tape
 driver should not be lying about its capabilities.
 
 Here is the patch:
 
 --- archive_read_open_filename.c        (revision 124)
 +++ archive_read_open_filename.c        (working copy)
 @@ -165,6 +165,15 @@
         struct read_file_data *mine = (struct read_file_data
 *)client_data;
         off_t old_offset, new_offset;
  
 +       /*
 +        * Workaround for broken tape interfaces that don't support
 +        * seek(), but return success if you ask them to seek().  This
 +        * also, of course, slows down archive scanning significantly
 +        * on devices that can seek.  Yuck.
 +        */
 +       if (S_ISCHR(mine->st_mode) || S_ISBLK(mine->st_mode))
 +               return (0);
 +
         /* Reduce request to the next smallest multiple of block_size */
         request = (request / mine->block_size) * mine->block_size;
         /*
 
 I request that the PR's class be changed to kernel (since the error is
 in a driver).