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

[Jeffrey Carlson]

Hi nn,


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

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.

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


> 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


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.


> 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 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.

> 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.
>

It seems like everything can read or write on this drive *except* ddrescue,
and that really puzzles me.


> > 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 less bothered if it's only 1300 MB I'm losing again, but is there no
way to make this file writeable by ddrescue? It seems like it should work
now. By the way, the file is editable in gedit: I just added a comment to
the top behind a # to check and saved it, and it's still there.

> 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?

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.
>

I think I'll get a spare drive and do this.


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


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



> > 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.


> Then the logfile is writeable? Why else
> would it show new positions?
>

I don't know. The logfile is writeable right now, even though ddrescue says
it isn't: I just added a comment to check and then closed it, and it was
still there when I came back.


> Now I'm confused! Or do you mean the status that ddrescue is showing
> while reading the drive?
>

I mean that everything on my computer except ddrescue indicates this file
is writeable but despite my having fixed all imaginable obstacles ddrescue
still says

ddrescue: Error opening logfile 'baby3.logfile' for writing.: Read-only
file system
Fix the problem and press ENTER to retry, or Q+ENTER to abort.

again every time I hit enter.


> 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?
>

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!


> 3. You tried to fix the output disk and logfile WHILE ddrescue continued
> to run?


ddrescue has just been repeating the error message I posted above for two
days now. I think it's halted, not reading or writing anything, just
holding the newest log data in its buffer and waiting until it believes the
file is writeable again. I didn't modify the logfile until just now, when I
added a comment behind # at the top just to prove that I could, but I did
eject and reinsert the output disk where the image lives, do chmod and
chown to make sure I had access, and do tune2fs to make sure it wasn't a
space issue. Space was too low initially for me to make a spare copy of
baby3.logfile, so it's possible that it was initially a space issue, I
guess, but that's no longer possible.

> 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.
>

Okay. Wheh!


> 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.

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!


Thanks again,
Jeff