Dear nn, Thanks for posting this to the list for me!
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? > But it looks like it's a bit more complicated. As it seems that there IS > already a logfile which was created before, but all of a sudden is > unwriteable. > So there are different ways something went wrong. > > You mentioned that there was an input/output error. I guess you did not > know which one of the drives (either the input drive or the output > drive) failed? > 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. > 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. > This is something for Antonio! He might want to see the logfile to seem > what might've gone wrong. Please wait until he tells you to send him > your logfile. > Certainly! > 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. Everything looks OK, but this command: > "sudo ddrescue -i 7435817400 -c64 /dev/sdc2 baby3.img baby3.logfile" > Where did you come up with the input position? I personally would not > recommend to use the -i option unless you REALLY, REALLY know what it > does and how to use it. (as referred to in the manual examples!) > The ddrescue was not going very fast, so I thought there was a specific point at which it was hanging that I needed to move past. I found the last successfully read block, and added the two numbers, which I believed to be the beginning of this successful block and its length. Then I added a few hundred to hopefully move past the error. The response was strange, in that the numbers for both "errsize" and "rescued" actually went DOWN. Eventually I halted that one and resumed without an input position, and the errsize and rescued numbers went back up to what they had been before. The error did not occur during the -i run or the one after, but two runs after. > OK, try this: > 1. Give us the output of ls -l from the "/media/jeff/[long hex name]" > directory you wrote the imagefile to. Just to see what file permissions > are set on the log file. > Sure. total 486317504 -rwxrwxrwx 1 jeff jeff 499113881600 Abr 21 05:48 baby3.img -rwxrwxrwx 1 jeff jeff 222184 Abr 21 05:45 baby3.logfile -rw-rw-r-- 1 jeff jeff 0 Abr 21 19:05 hello.txt drwxrwxrwx 2 jeff jeff 16384 Abr 10 21:47 lost+found > 2. Try to copy the logfile somewhere else (preferably your home > directory) and then run ddrescue with this command > > jeff@baby4:/media/jeff/f1611274-1f7d-4b32-9475-1ac91c0da6d2$ sudo > ddrescue -n -d -r1 /dev/sdc2 baby3.img /home/jeff/Desktop/baby3.logfile > > Notice the /home/[username]/ that will point it to your home directory. > I'm sure it is "/home/jeff/". Of course you can copy the logfile > wherever you want. See if it still give the write error. > 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. > 3. You should take a look on the logfile itself. Try to open it with a > text editor and see if it looks similiar to the example given in the > manual > ( > https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Mapfile-structure > ) > > If it is garbled or does not look anything like the example the logfile > might be corrupted? > 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. If it is a regular logfile then I'd recommend waiting for Antiono's > answer and email him the baby3.logfile, when he is requesting it. > Will do. > > It's good to know I can write the log file anywhere. Is there a way I > > can switch the target of the *current* run (which gives me the prompt > > above) to my local drive to circumvent the lack of writeability that > > ddrescue is claiming? > > Yes, see the example above. (#2) 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)? Thanks again, Jeff _______________________________________________ Bug-ddrescue mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-ddrescue
