Re: [Bug-ddrescue] Logfile won't write: claims drive is read-only

[nn]

Hi Jeffrey,

On 24.04.2016 10:29, Jeffrey Carlson wrote:
>
>     The short answer is: yes! Your progress will be lost.
>
>
> This is disappointing! You mean my progress since the last write to
> the logfile, or all nearly 500GB of progress?

The progress until the last successful written logfile will be saved.
Looking at the status you posted you will lose about 1300MB of data.

See, the logfile is used to mark unsuccessful reads. Everything that was
read OK is saved to the image file. The sectors that are not OK will
also be written, but in the form of a placeholder. They will be filled
with rescued data in the repeated attempts after the first try. 
497982MB (497GB) of your data is rescued. The rest is marked to be
retried. Ddrescue automatically determines the positions that are not OK
and retries them in the second run.

TBH, 497GB of successfully rescued data is quite good. I don't know what
files you are trying to recover, but it is better to try rescuing data
from this image file than retrying to rescue 100% of the drive! Whatever
is causing the failure of your drive, might have destroyed some data. If
it is a physical error it is hard to rescue from those sectors.

The real problem is, the longer you are running ddrescue, it is more
likely that the drive will fail completely. (Physically!) No matter if
the logfile is writeable or not.

>  
> I believe that the drive to which the file was output was temporarily
> unplugged (it was jostled, at least, near to when the error occurred),
> and this caused the error. I cannot be sure of anything though. When I
> replugged it, it came back as read-only. When I fixed that, there also
> wasn't very much space. I freed up 2 GB on the partition by lessening
> the proportion reserved for root using tune2fs.
>
> The "Read-only file system error" persisted through all this. It was
> true the first time, but all the tools I know indicate it is no longer
> true.

I believe you might've fixed the read-only problem.

>  
>
>     My guess is that the output drive somehow failed and messed up either
>     file permissions or simply messed up the whole logfile.
>
>
> Maybe. There's nothing obviously wrong in the last-written version of
> the logfile, which I've since backed up.

That's good.
But as per your "ls" query and inspection of the logfile, it is OK and
should be writeable. (even though it is not necessary to be executable)

>  
>
>     Just to make sure. When did the write error occur? After which
>     command?
>     I guess the first one worked fine, but did not work after that?
>
>
> The error only occurred after the last one. I haven't tried running
> again since the error. I've kept my computer on, in one place, for a
> few days now, hoping to find a way to write this logfile without
> pressing Q+ENTER.

It will not work. You need to stop the process. If the logfile is not
writable since you started ddrescue it is no use at all. The errors that
were recovered after the last rescue attempt will be lost, no matter
what you will do, assuming the logfile is still not writeable.

>
> I'm hesitant to do this because I'm worried I haven't communicated
> clearly: I'm still trying to write to the other logfile; I haven't
> quit yet. I'm worried that it would be bad to run two ddrescues on the
> same image at once? It sounds dangerous, at least if baby3.img isn't
> already useless.
>  

Of course. Don't run two ddrescue operations! The baby3.img is NOT
useless. You already have 497GB or RESCUED data! If you use the same
logfile up until the point it was writable the last time, it will only
retry and rescue those sectors it has marked as unreadable.

If your really, really want to make sure you won't lose ANY data: Stop
ddrescue, backup the baby3.img and baby3.logfile on a seperate disk (if
you have a spare drive with 500GB free space!) and restart ddrescue and
see if the logfile error is still there.

As said above. It depends on what you want to be rescued. 497GB is a lot
of data.

>  
> It looks totally normal to me. I'd been looking at it every once in a
> while (not editing it, just refreshing to see its progress and the
> exciting new positions it was finding) during the last run, and it
> looks more or less the same as ever.
>

Wait? You tried to access the logfile while ddrescue is working? And it
showed you the new positions? Then the logfile is writeable? Why else
would it show new positions?
Now I'm confused! Or do you mean the status that ddrescue is showing
while reading the drive?

To be honest I'm not quite sure what you really did.
I'm trying to recreate your procedure.
1. You start ddrescue with the commands you posted. Everything works OK
until the last command, which then returned the error on the logfile?
2. The output drive had an i/o error and ddrescue aborted? Or did it
keep on running and didn't stop?
3. You tried to fix the output disk and logfile WHILE ddrescue continued
to run?

>
> Okay, I've gotten confused again, so I want to check to make sure I
> understand before I misinterpret and do something incorrect: you are
> saying that I can, WITHOUT hitting Q+ENTER to exit my current,
> two-days-halted but still-active run of ddrescue, start a DIFFERENT
> ddrescue with the same source drive and target image file, but writing
> the logfile to a different place, without damaging the current image
> file (or worse, the source drive)?
>
No, you should stop the current ddrescue operation. The logfile is there
to resume the operation when even if you stop ddrescue. The image file
you already have will not be destroyed, as long as the logfile is still
there.

As said above i'm not quite sure if you really stopped ddrescue ad
restarted the operation after the i/o-error, because you feared that
ddrescue might've to do the whole process again or overwrite rescued data.


If you are still unsure, wait for Antonio to reply to your problem.
Sorry, I'm getting a bit confused now i try to retrace your steps. Feel
free to ask away anyway. I'm sure there is a solution for your problem.


Regards.