Are there alternatives for `dd`?

Question

What tools other than dd should I use to read and write files with truncation, seeking and skipping? dd's command line options seem inconvenient and foreign and I don't like choosing between slow, but precise seeking mode (bs=1) and fast, but inflexible mode (bs=4k or whatever).

Are there more modern tools to read 555 bytes from one file (or pipe or socket or dev) from position 31337 and write them to the other file at position 128205 (using blocks 512+43), with or without truncation?

Solution 1

dcfldd is another dd alternative. It doesn't address the OP's question about input/output seek flexibility, but may be useful to others arriving here via google search.

It's based on gnu dd, with the following additional features:

• Hashing on-the-fly - dcfldd can hash the input data as it is being transferred, helping to ensure data integrity.
• Status output - dcfldd can update the user of its progress in terms of the amount of data transferred and how much longer operation will take.
• Flexible disk wipes - dcfldd can be used to wipe disks quickly and with a known pattern if desired.
• Image/wipe Verify - dcfldd can verify that a target drive is a bit-for-bit match of the specified input file or pattern.
• Multiple outputs - dcfldd can output to multiple files or disks at the same time.
• Split output - dcfldd can split output to multiple files with more configurability than the split command.
• Piped output and logs - dcfldd can send all its log data and output to commands as well as files natively.

Solution 2

There is the tool ddrescue (watch out, there is also dd_rescue which is a different program with almost the same functionality). It uses the more familiar syntax with the single dash for short or double dash for long options. From the man page:

   -i, --input-position=<bytes>
          starting position in input file [0]

   -K, --skip-size=<bytes>
          initial size to skip on read error [64 KiB]

   -M, --retrim
          mark all failed blocks as non-trimmed

   -o, --output-position=<bytes>
          starting position in output file [ipos]

Solution 3

A good alternative is pv. Not only does it automatically calculate the most efficient block size, essentially speeding things up, but it also provides progress, among other things. It's use is simple:

pv < /dev/sda > sda.img

It plays well with compression too. A fast way to backup and compress a disk in one move is like so:

pv < /dev/sdb | pigz -9 > disk.img.gz

You can learn more here.

Comments

[Vi.]

ddrescue - - -> Infile and outfile are the same., ddrescue /dev/stdin /dev/stdout -> Infile and outfile are the same.. Bad beginning of the story...

[Marco]

I just tried with dd_rescue. It throws a warning that the file (stdin) is not seekable, but proceeds. You can give it a try. However, ddrescue feels more full-featured and mature.

[Warren Young]

@Vi.: Don't shoot the messenger. ddrescue is right, pipes aren't seekable. If you want to start reading at a specific point in a file, you need to give it access to the file in question, not data piped from another program. Also beware that using pipes fights against this wish of yours for ultimate speed, since the only way to emulate seeking in a pipe is to read and throw away the parts you don't want to process. Seeking within an actual file is far more efficient.

[Lightness Races in Orbit]

Indeed, since the tool is designed for rescuing broken data, there is no pipe capability. This is a bit of a shame when you want the flexibility of seeking through an input file but just want to pipe the result to stdout. For its intended purpose, though, it's great.

[Vi.]

Main expected feature is seeking in output and input files, which pv (pipe view) does not provide, as there is no seek for pipes.