tar error unrecoverable?

[Curt Tresenriter]

On Sat, 25 Jan 2014 17:12:50 +0000
Colin Law <clanlaw at gmail.com> wrote:

> On 25 January 2014 12:10, Curt Tresenriter <ctres at grics.net> wrote:
> > ...
> > Meaning... When I attempted (failed being implied here) to copy
> > back to it's original home is when the error occurred. The result
> > was 3GB of the file transferred before Nautilus reported the IO
> > error.
> 
> If you are getting an error when you copy the file then it is nothing
> to do with tar, the problem is reading the original or writing the
> copy and is probably a hardware issue of some sort.

I haven't been able to verify the health of the disc yet. (#2 disc) 

> You should be able to tell from the error which disc it was trying to
> access when it failed.  There may well be something in
> /var/log/syslog.
> 

I looked at the log at the time and didn't see anything that looked
suspicious.

Earlier I tried using dd with the noerror option to copy back to
the original disc. syslog shows:


Jan 25 12:27:14 paduak kernel: [489286.056277] sd 18:0:0:0: [sdf] Unhandled sense code
Jan 25 12:27:14 paduak kernel: [489286.056287] sd 18:0:0:0: [sdf]  Result: hostbyte=invalid driverbyte=DRIVER_SENSE
Jan 25 12:27:14 paduak kernel: [489286.056298] sd 18:0:0:0: [sdf]  Sense Key : Medium Error [current] 
Jan 25 12:27:14 paduak kernel: [489286.056308] sd 18:0:0:0: [sdf]  Add. Sense: Unrecovered read error
Jan 25 12:27:14 paduak kernel: [489286.056319] sd 18:0:0:0: [sdf] CDB: Read(10): 28 00 00 fc fc 3c 00 00 01 00
Jan 25 12:27:14 paduak kernel: [489286.056340] end_request: critical
target error, dev sdf, sector 132637152


Looks to me that the copied file is corrupted if I'm interpreting the
log correctly.
Of course the original was deleted - not just trashed - so I'll never
know if it was corrupted or not.


> In your very first post you said that it was when trying to unpack it
> that it failed, now you seem to be saying that it first failed during
> copy operations.
> 
> Colin
> 

I think you get that impression due to the fact that in this response I
was just replying to your examples.

The whole thing happened in the order I posted, but I didn't mention
that I had first copied to another disc - then at your suggestion I
tried to copy back to the original disc to see if I could eliminate
hardware as a possible problem.

It copied to the second disc (the very first operation of this
fiasco) with no noticeable error.
Unpacking on the 2nd disc was the first error, copying back (the second
time I attempted to copy it) to the original disc was the second time
I got the IO error.


In any case I am presently running bzip2recover on the file after
recompiling - because I had to change the MAX_HANDLING_BLOCKS value to
accommodate the huge file size.