A simple way to transfer photos from your phone to Windows withoutinstalling anything on either
ultred ragnusen wrote:
I'll read up s'more on ddrescue. Thanks. We should probably take this out
of the r.p.d ng because it's off topic so I'll post a separate thread.
If you have something like Ubuntu, try "gddrescue".
The package name and the executable name, don't have
to be the same. That's what adds to the joy of figuring it out.
ddrescue is a utility that tolerates "CRC error" when reading
a disk. You can make one run after another, and the "log" file
keeps track of what sectors have not been recovered yet. Looking
at the log, you get some idea how much damage remains (in terms
of CRC errors).
The items are
You present the same log file to the tool, every time you
run the same source and dest. The log file gets updated when
hard-to-read sectors are finally captured. Eventually, after
enough passes, there will be some sectors that will never be
read. And you hope that those are replaced by zeros. Then,
if you run CHKDSK on that destination drive, it might be
able to restore enough of the disk, to get (most) of the
data off it.
ddrescue is mechanical and captures sectors. It doesn't know
or care whether the partition is NTFS or EXT4. Doesn't matter.
It relies on other tools, to make sense of what it captured.
The "logical" state of the file system is another matter
entirely. For example, my Windows 10 Insider partition that
had volume bitmap corruption and some damage to Extended Attributes,
I could use ddrescue on that hard drive, and it would complete
the transfer in only one pass (the log file would be clean).
No second pass would be needed. But in order to correct the
damage on the disk, it takes a couple CHKDSK commands to finish
I don't really care all that much, what happens to my
Windows 10 Insider installs, as Windows 10 is the "software
as a service" OS, and it should "run like a King". It's
simply not possible for a product like that, to be bricked...
Right ? :-/
This would be an example of backing up a hard drive, to an
"image file". The "image file" could be restored to a new hard
drive later, say. The "S" argument in this example is sparse.
For experiments of this kind, I can prepare /dev/sdb in advance
to contain mostly zeroed data files. When the backup is
written out, it need not take much space on the storage
device. This allows backup experiments with only a small amount
of real space on the destination. I think the -b parameter
sets the max transfer size. The command is adaptive and
adjusts the block transfer according to how "bad" the disk
is. The block size is increased, as long as it improves the
overall transfer rate. If the fastest transfer is happening with
4KB blocks, then it'll use 4KB transfers instead.
ddrescue -S -b8M /dev/sdb /mount/external/backup/sdb.raw /mount/external/backup/sdb.log
Because there was nothing wrong with the disk, I had no real
opportunity to craft a "second pass" command for it. So that
command is for the first pass. You can open the log in a
text editor, and see what remains to be transferred and whether
another pass is required.