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

[nn]

Hi Jeffery,

First of all:

>     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.
>
>
> That *is* what I was worried about, but I have *not* stopped ddrescue
> and restarted since the I/O error. 

THIS is your main error! You kept doing things WHILE ddrescue was still
running. The logfile is not accessible as some process is still in use
by some process in memory! And ddrescue is looking for something that is
not there.


> Okay, this is much less worrisome. I wasn't sure about the interaction
> of the logfile with the image, and in particular, if the logfile being
> wrong meant the image recovery couldn't continue. This is a great relief.

As you said the file doesn't look any different then the example in the
manual, so i guess it is ok. And as you already made a copy at some
point i guess, most of the data might be still ok.

>
> BTW, where do you get 1300MB? The difference since the last run
> between the rescue amounts is 2MB. Am I misunderstanding these numbers?

I was referring to the status message you posted in your first mail,
which was:

GNU ddrescue 1.17
Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:   497982 MB,  errsize:   1131 MB,  errors:    3727
Current status
rescued:   497984 MB,  errsize:   1129 MB,  current rate:        0 B/s
   ipos:    15227 MB,   errors:    3917,    average rate:      136 B/s
   opos:    15227 MB,    time since last successful read:     1.2 m
Splitting failed blocks...

The error size was 1131MB. I just recalled it from memory and i thought
it was 1300MB. I shoul better check twice when quoting. ;)

>  
> But I can still try to work with the image file later, right, and it's
> better to have more to work with, right? I'm pretty sure there's a
> physical error and some is lost, but I'd like to maximize what I can save.

Yes. Other operations like file recovery with other software should be
done on the image file. But this is not something for ddrescuse.

> I don't think the drive is safe to use anymore, and will probably fail
> completely anyway, so I am more concerned with maximizing the amount
> of data saved. I'm not sure if this is a reasonable position or not;
> maybe if the drive were repairable (it's a Mac drive that won't boot
> on it's own or show up on another Mac in "target mode"), that would be
> something to think about. 
>
If you managed to get back the data you want from the backup you already
have, it is still worth a try to leave ddrescue try running a bit longer
and see, if maybe things can be rescued. In the end it doesn't, matter
if the drive fails while ddrescue is running, or if it fails on some
other operation.

>     > 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.
>
>
> I see. So its first task would probably be going over those same last
> bits it had gone over again?

You mean doing the sectors and failed sections of the drive? It tries to
read again everything that is "non-rescued". Everything that was marked
OK is not read again.

>  
> Yes, I'm happy with how well it's done, but want to save as much as
> possible.

You already did. copying the image file now to another disk at least
gives you double security.
>
>  
>
>     > 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? 
>
>
> Yeah, I had it open in gedit. It would tell me there had been changes
> and ask me to refresh it, and when I refreshed it, there'd be more
> lines at the bottom showing the new blocks it had been looking at. I
> wasn't trying to write on it, just monitoring the changes.

This is not how you should use ddrescue. You tried to view the logfile
while ddrescue is running, and you didn't stop the process in the first
place.

TBH this is something for Antionio Diaz. It's a user error.

>  
> Yes. The last command worked fine too for about an hour or so, and
> then when I checked after the USB cord had been bumped I had the I/O
> error message.
>  
>
>     2. The output drive had an i/o error and ddrescue aborted? Or did it
>     keep on running and didn't stop?
>
>
> ddrescue is still open! I made sure the drives were both connected
> properly and hit ENTER. Then I got a new error message, that the
> logfile couldn't be written because it was a read-only file system.
> Then I made sure everything was writeable in all the ways I could
> think to do, but ddrescue, still open, is still giving this same error
> message!

Simply stop ddrescue (hitting ctrl-c or q-enter; i'm on linux not Mac).
Make the suggested backup (!!!!!!!!!!). Retry the command and see if the
error is still there.

If there are new errors done by the i/o error to the img file no matter
what you do, stopping or keep ddrescue running won't make a difference.

>
>     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.
>
>
> I'm so unsure about so many things now. I feel reassured that most of
> baby3.img is safe, but I'm really confused why I can't write on this
> logfile now, and kind of want to do so not for the data even anymore,
> but just on principle: it should write!

You didn't stop ddrescue after the I/O-error and kept fiddling around
the logfile while ddrescue tries to access the file also. This always
leads to problems.