bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jim Meyering
Subject: Re: "cp -a" not consistently reporting error on cdrom read error
Date: Mon, 26 Feb 2007 21:13:40 +0100

Joe Peterson <address@hidden> wrote:
> Hi, I hope this is the correct forum in which to ask this...

Yes, it is.

> 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 for reporting it.
If you can reproduce the failure (i.e., incomplete copy, but no
diagnostic from cp) while running cp via strace, then maybe we can
determine if it really is a bug, and if so, maybe even where:

    strace -o /tmp/log cp -a /media/cd... /your-dest

Then /tmp/log will show us the syscalls cp made along with their
return codes.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]