Re: "cp -a" not consistently reporting error on cdrom read error

[Joe Peterson]

Jim, I tried replying directly to address@hidden, but it bounced saing
"access denied".  Is there some filter blocking me?

So I am sending my reply again to this address (which worked before).  -Joe

----------------

Hi Jim, and thanks for the reply.  I am now trying to get this to repeat
using strace.  It seems harder and harder to get it to happen, but maybe
I'll get lucky, and I will send you the log as soon as I see it.

        Thanks, Joe




Joe Peterson wrote:
> Hi, I hope this is the correct forum in which to ask this...
> 
> I have been trying to read a particular cdrom that seems to be of
> "marginal" quality.  I often get cdrom read errors reported in my
> /var/log/messages file, but when these errors happen, I do not always
> get an error reported from the "cp" command in coreutils - rather, the
> file is just not completely copied (i.e. resulting file is too short).
> This is a little disconcerting, of course.  Are there cases in which cp
> would not report an error even when not writing the full file?
> 
> I am running Gentoo Linux with coreutils 6.4 and kernel
> 2.6.19-gentoo-r5, but the problem also happened on kernel 2.6.18.
> 
> The reason I suspect coreutils is that if I repeat the cdrom read (using
> "cp -a"), producing the short file repeatedly, and then I run "rsync
> -av" instead, rsync reports the read error, whereas cp did not.
> 
> Note that most of the time I *do* get an error from cp:
> 
>       cp: reading `/media/cd/co_d02/co_d02.tpc': Input/output error
> 
> But not always.  Also, when I try repeatedly, I often get the error
> right away, as if the read attempt has been buffered.  I wonder if I
> also get in this "buffered" state when it is not reporting the error...
>  Not sure if this is related or what part of the system is doing the
> buffering.
> 
> I know I have not provided a great deal of info, but I have been
> unsuccessful at finding info about this, even in the coreutils
> ChangeLog, and the problem is rather hard to reproduce.  Any insight or
> ideas would be appreciated!
> 
>       Thanks, Joe
> 
> 
> 
> Here is an excerpt from /var/log/messages:
> 
> Feb 24 10:31:03 crater hdc: media error (bad sector): status=0x51 {
> DriveReady S
> eekComplete Error }
> Feb 24 10:31:03 crater hdc: media error (bad sector): error=0x30 {
> LastFailedSen
> se=0x03 }
> Feb 24 10:31:03 crater ide: failed opcode was: unknown
> Feb 24 10:31:03 crater ATAPI device hdc:
> Feb 24 10:31:03 crater Error: Medium error -- (Sense key=0x03)
> Feb 24 10:31:03 crater (reserved error code) -- (asc=0x15, ascq=0x00)
> Feb 24 10:31:03 crater The failed "Read 10" packet command was:
> Feb 24 10:31:03 crater "28 00 00 05 12 9f 00 00 08 00 00 00 00 00 00 00"
> Feb 24 10:31:03 crater end_request: I/O error, dev hdc, sector 1329788
> Feb 24 10:31:03 crater Buffer I/O error on device hdc, logical block 332447
> Feb 24 10:31:03 crater Buffer I/O error on device hdc, logical block 332448
> Feb 24 10:31:03 crater Buffer I/O error on device hdc, logical block 332449
> Feb 24 10:31:03 crater Buffer I/O error on device hdc, logical block 332450
> Feb 24 10:31:03 crater Buffer I/O error on device hdc, logical block 332451
> Feb 24 10:31:03 crater Buffer I/O error on device hdc, logical block 332452
> Feb 24 10:31:03 crater Buffer I/O error on device hdc, logical block 332453
> Feb 24 10:31:03 crater Buffer I/O error on device hdc, logical block 332454
> Feb 24 10:34:45 crater hdc: cdrom_decode_status: status=0x51 {
> DriveReady SeekComplete Error }
> Feb 24 10:34:45 crater hdc: cdrom_decode_status: error=0x40 {
> LastFailedSense=0x04 }
> Feb 24 10:34:45 crater ide: failed opcode was: unknown
>