GNU bug report logs - #17149
shred - tape data

Previous Next

Full log

Message #44 received at 17149 <at> debbugs.gnu.org (full text, mbox):

From: Rupert Russell <Rupert.Russell <at> ilmor.co.uk>
To: 'Pádraig Brady' <P <at> draigBrady.com>
Cc: 'Paul Eggert' <eggert <at> cs.ucla.edu>,
 "17149 <at> debbugs.gnu.org" <17149 <at> debbugs.gnu.org>
Subject: RE: bug#17149: shred - tape data
Date: Wed, 2 Apr 2014 15:59:42 +0000

Pádraig,

So, I think this means there isn't a bug. The behaviour I observe is from a decision made to work in this way  and so my scripted workaround is the way forward.

Regards

Rupert Russell
OPERATIONS MANAGER



Ilmor Engineering Ltd
Quarry Road, Brixworth, Northamptonshire, NN6 9UB, UK

Direct:     +44 (0)1604 799105
Main:       +44 (0)1604 799100
Web:       www.ilmor.co.uk


-----Original Message-----
From: Pádraig Brady [mailto:P <at> draigBrady.com] 
Sent: 02 April 2014 15:55
To: Rupert Russell
Cc: 'Paul Eggert'; 17149 <at> debbugs.gnu.org
Subject: Re: bug#17149: shred - tape data

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.

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com ______________________________________________________________________

______________________________________________________________________

This e-mail may contain confidential and /or privileged information. If you 
are not the intended recipient (or have received this e-mail in error)please 
notify the sender immediately and destroy this e-mail. Any unauthorized copying, 
disclosure or distribution of the material in this email is strictly forbidden.

This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.