Subject: Re: bug#17149: shred - tape data

From: Pádraig Brady <[email-masked]>
Date: Wed, 02 Apr 2014 15:55:16 +0100

On 04/02/2014 09:03 AM, Rupert Russell wrote:
> Paul,
> 
> Interesting challenge you set extracting the last few lines from a 4 gig file, but I've passed that test I think. (Used Less..)
> 
> 
> read(3, "..., 12288) = 12288
> write(4, "..., 12288) = -1 ENOSPC (No space left on device)

So we got ENOSPC and didn't warn about that,
but rather just used that info to determine the end of the device.
That also implies that the initial lseek (fd, 0, SEEK_END)
on the device did return a failure (which we ignored by design).

> write(2, "/dev/st0: pass 1/3 (random)...19"..., 48) = 48

> sync()                                  = 0

> lseek(4, 0, SEEK_SET)                   = 0

We ask here to "rewind", which returns "successfully"

> write(2, "/dev/st0: pass 2/3 (random)...", 30) = 30

> read(3, "..., 12288) = 12288
> write(4, "..., 12288) = 12288

I'm a bit surprised this first write passes

> read(3, "..., 12288) = 12288
> write(4, "..., 12288) = -1 ENOSPC (No space left on device)
> write(2, "/dev/st0: error writing at offse"..., 39) = 39
> write(2, ": No space left on device", 25) = 25
> close(4)                                = 0

So now we know the size of the device, we correctly warn about this error.

The key point is the lseek(4, 0, SEEK_SET) returns success here for the tape device.
I guessed that this was by design, but let's just delve into the code a little...

  http://lxr.linux.no/linux+v3.13.5/drivers/scsi/st.c#L1176
    static int st_open(struct inode *inode, struct file *filp) {
      /*
       * We really want to do nonseekable_open(inode, filp); here, but some
       * versions of tar incorrectly call lseek on tapes and bail out if that
       * fails.  So we disallow pread() and pwrite(), but permit lseeks.
       */
    }
  And the lseek() maps to a noop that just returns the current file pointer.

thanks,
Pádraig.