[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#17149: shred - tape data
From: |
Rupert Russell |
Subject: |
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:address@hidden
Sent: 02 April 2014 15:55
To: Rupert Russell
Cc: 'Paul Eggert'; address@hidden
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
- bug#17149: shred - tape data, Rupert Russell, 2014/04/01
- bug#17149: shred - tape data, Paul Eggert, 2014/04/01
- bug#17149: shred - tape data, Rupert Russell, 2014/04/02
- bug#17149: shred - tape data, Pádraig Brady, 2014/04/02
- bug#17149: shred - tape data,
Rupert Russell <=
- bug#17149: shred - tape data, Paul Eggert, 2014/04/02
- bug#17149: shred - tape data, Paul Eggert, 2014/04/02
- bug#17149: shred - tape data, Pádraig Brady, 2014/04/02
- bug#17149: shred - tape data, Paul Eggert, 2014/04/03
- bug#17149: shred - tape data, Rupert Russell, 2014/04/03
- bug#17149: shred - tape data, Pádraig Brady, 2014/04/03
- bug#17149: shred - tape data, Paul Eggert, 2014/04/03
- bug#17149: shred - tape data, Pádraig Brady, 2014/04/04
- bug#17149: shred - tape data, Paul Eggert, 2014/04/04
- bug#17149: shred - tape data, Rupert Russell, 2014/04/04