Katona Gábor wrote:
> Antonio wrote:
>> Florian Sedivy wrote:
>>> Or the syntax check could have a "loose mode" used only for rescue-domain
>>> log files (and maybe also in fill mode?). It would be enough to only check
>>> the lines that will actually be used, and those by the rule, that they
>>> "must be strictly ascending and non-overlapping".
>>
>> This is an interesting idea. I'll see how to implement it.
> I didn't check the internals of treating domain logfiles, so maybe the answer
> to the following will be strict no. I'm wondering is it possible not to have
> any restrictions on the domain logfile? In my mind domain logfile is simply a
> file which defines domains which should be rescued *separately*. In this
> sense randomly positioned or even overlapping ranges are possible, since
> ddrescue would simply walk through the domains and would try to copy yet
> uncopied parts. If some parts are present is multiple domains, no problem. If
> these parts are already copied, nothing to do. If they are not copied, let's
> try. Treating domain logfile like this would make it unnecessary to create a
> valid logfile from a file like mine defining separate domains.
I absolutely agree with Gábor, sequential processing is the consequent way to
do it. We could specify in such a "free style" domain the order in which to try
blocks and explicit retries. ddrescuelog might also be enabled to create such a
sequential domain-logfile from a pre-ordered list of blocks.
To complement that, there should be the option to deduce the (sequential)
rescue domain from all the lines present in the domain-logfile (instead of only
"+"), simply ignoring the status field. This would give the opportunity to make
a copy of a real log file from an incomplete first run, edit out all areas that
are not important, rearrange the rest by priority, and continue rescuing,
without having to change all lines to status "+".
Btw, I would wish for an option to exit a run _before_ the trimming phase (e.g.
-N, —no-trim), because trimming already switches from cluster- to
block-reading.
But all this leads to more changes in code than just loose syntax checking, I
guess?
Taking that line of thought even a little further:
Sequential processing would bring the domain-logfile more to something like a
batch file, which opens the question, if even more could be done in this
direction (e.g. execution directions beyond order and location of blocks). On
the other hand, the syntactical compatibility with "regular" complete logfiles
has a lot of advantages too, so that should not be broken.
One possibility would be to use the different status markers from the
domain-logfile in their original meaning to override the "initial status read
from log file" just once at the beginning of the run (first or last occurrence
of the same block wins). This would allow to selectively retrim or re-copy
certain areas without having to alter the original (regular) log file.
Finally, using only a domain-logfile with status-overrides _without_ a regular
log file, the domain-logfile would become the sole source for the "initial
status" of a block. Strictly processing the domain-logfile line by line -
together with the new enhanced logging-features of ddrescue - could come in
handy for all sorts of test-cases.
Greetings, Florian
_______________________________________________
Bug-ddrescue mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-ddrescue
