[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Hello ddrescue team
From: |
ricardo.ortega |
Subject: |
RE: Hello ddrescue team |
Date: |
Wed, 2 Jun 2021 12:15:54 -0500 |
Thanks for your Reply
I use ddrescue in a regular basis to clone severely damaged disks
So, the process runs for days or even weeks
To pause, scan for used sectors (directories, data files) is a time
consuming task and we must scan the whole disk
Your mapfile will remain as is. I understand the whole mapfile and is
perfect as is. I intend to create a new sectorcontents logfile (zero, start
of pdf, start of xml, start of ... some magic we may need)
I intend to add a feature to my copy of ddrescue intercepting the iobuf()
may be in the same lines of code you detect zeros
I want to analyze the chunk of data and store the result in A SEPARATE file,
same syntax as your logfile (magic found byteoffsetHex bytecountHex)
This separate file will avoid further scanning to extract contiguous files
or very large files as vmdk vhd or vdi files
Another utility mapping the sectorcontent logfile (only cloned areas
matching ddrescue logfile) may give an overview of the contents of the media
As I stated, I am an advanced and experienced C, Asm, PHP, Bash programmer
(20+ years and thousands of lines), But I skip C++ so I need your help
Thanks in advance
Español:
Tu nombre es latino / español. Mi intención es (sin tocar al
logfile/mapfile) agregar un nuevo archivo (opcional) a mi copia de ddrescue
para indicar el contenido de varios tipos de signatures (mbf, gpt, vdi,
vhdx, vmdk, pdf, zero, etc.) De esa manera no necesito escanear con r-studio
o similares todo el disco sino solamente las regiones que me interesan
(vmdk, partición seleccionada, etc.)
Lo que ocurre es que muchos dispositivos llegan con daños muy graves y no es
posible reconocer el filesystem como para usar los ddrutilities como
ntfsbitmap o similares. Además trabajo con dispositivos en otros formatos:
ext, xfs, hfs, mac, Android, DVR, etc.
Al momento ya he realizado varias mejoras visuales a ddrescue incluyendo
entre otras, una traducción al español (70% de texto). Podría enviarles
capturas de pantallas ya que un diff no sirve porque no creo les interese
dejar ddrescue en español ...
Gracias por adelantado
Ricardo Ortega
-----Mensaje original-----
De: Antonio Diaz Diaz <antonio@gnu.org>
Enviado el: miércoles, 02 de junio de 2021 10:59
Para: ricardo.ortega@libresoft.ec
CC: bug-ddrescue@gnu.org
Asunto: Re: Hello ddrescue team
Hola Ricardo.
Ricardo Ortega wrote:
> Congratulations for your job
Thanks.
> I suggest you to add some sort of sectormap to ddrescue to identify if
> a block is zeros (null or binary zeros)
Ddrescue is already able to detect blocks of zeros (for --sparse), but I do
not understand what exactly do you mean with "sectormap". Adding a new field
to each line of the mapfile cannot work because each line may comprise a
large number of sectors with different signatures. OTOH, a log file with an
identifier for each finished sector would be huge.
> I would suggest a plugin to analyze the sector / block contents (in
> sector
> chunks) to identify in a single pass or in a single map the actual
> contents of the cloned regions (zero, mbr, boot sector, start of pdf,
> etc. I can handle all this. I have a large collection of signatures,
> so, the task is suited for me. But the mapfile.cc file and the
> rescuebook.cc file exceeds my
> C++ expertise and I do not want mess with these files
Classifying the type of sector given a list of signatures is trivial, so no
plugin needed. The real problem is where to store, or how to communicate
such large amount of information to the program that will process it (show
it to the user or something).
> The objective is to determine as easy as ddrescueview the actual
> general contents of the cloned regions (zeros, start of partition,
> start of pdf, start of any magic the user wants) in a C header, in an
> ini or .signature file or else you may decide
Ddrescueview can provide an overview of the types of sectors because the
mapfile is kept as small as possible, same kind of sectors are coalesced,
and the amount of possible statuses is small (allowing different colors for
each one). I don't see how this could be scaled to individual sectors and a
large diversity of sector types.
Best regards,
Antonio.