What's the difference between dd and cat for writing image files?

When writing image files to disk or to a USB stick, the instructions usually use dd, like this:

dd if=myimage.img of=/dev/sdb

How is this different from, say:

cat myimage.img > /dev/sdb

I realize that dd has many more options, like count=..., but if the purpose of the exercise is to write an entire file to a device, what's the advantage of using dd?

This question is like "I have this one tool that can draw rectangles and the other that can draw rhombuses; which one is the right tool to draw a square?"

Any square is a special case of rectangle and a special case of rhombus, so either one of the two tools can be used.

The same is with dd and cat. The former can do conversion, skip and seek, adjust buffer size; but in the simple case it just reads one file (or block device) and writes raw data to the other. The latter can concatenate multiple files into one stream with some optional textual modifications, but in the simple case there's just one input file the content of which is streamed (with the shell support) to the output file or device.

Both tools are useful and none can be discarded in favor of the other. Their scopes just overlap at this simple case you ask about.

Having said that, I think there are at least two issues that make dd the better a reasonable choice.

1. Block device permissions

To write to a file or device cat needs its output to be redirected. Your shell does the redirection i.e. opens the target file. While redirecting to /dev/sdb you will probably hit "permission denied" unless you are logged in as root. Running a shell as root is risky and should be avoided.

You may try

sudo cat myimage.img > /dev/sdb

and fail because sudo doesn't affect output redirection done by the shell.

On the other hand this is completely non-problematic:

sudo dd if=myimage.img of=/dev/sdb

A little hint by the way: if you find yourself in a situation where you must redirect the output to a file with restricted access then you may use this trick:

some_command | sudo tee restricted_file > /dev/null

That leads us to yet another way to do the job. The command tee passes its input to multiple files and to standard output. In simple case there is one file and the standard output is discarded:

sudo tee /dev/sdb < myimage.img > /dev/null

In this case there is also input redirection not affected by sudo.

2. Stepping beyond simple case

Imagine a carpenter who makes kitchen tables. Most tables have rectangular top surfaces; rhombus shaped ones are far less common. There is a table with square top to be made. A square is a rhombus, also it is a rectangle. Will the carpenter use methods that apply to rare rhombus shaped tables? or to common rectangular tables? Both sets of methods should work with square table, nevertheless he makes rectangles every single workday, so there is no point in changing the approach.

Back to cat and dd. In my opinion (and my practice) there is hardly ever a need to concatenate several images in order to write them all to block device. That definitely would be a job for cat. The tool can do something more but you don't want it: the options target text files so they can invalidate your binary data when used with image file.

Now, the options provided by dd are often useful to me when I read from or write to a device:

• conv=noerror – when the source may be faulty; actually no, do not use conv=sync,noerror; when the source may be faulty use GNU ddrescue;
• bs=… – large buffer won't exhaust my HDD;
• count=… – to read a fragment, like MBR;
• conv=sparse – to reduce image size in some circumstances.

There's more. This command:

kill -s USR1 $(pidof dd)

makes dd print I/O statistics to standard error. I don't think you can do this with cat.

These are the reasons I consider dd to be the natural tool for working with raw images. I see no point in changing the tool to cat just because there's no difference in some special case, but I see another reason (below). I'd like to think the instructions usually use dd because their authors think like me. There is some elegance in ability to consciously choose the right tool, especially when there are more that seem equally suitable.

Still dd is a cranky tool which is hard to use correctly. Anyone's ability to consciously choose the right tool should include being aware of this fact. If you're not sure you can use dd correctly then probably the right tool for you is not dd.

If you're sure you can use dd correctly then mind the Dunning–Kruger effect and ask yourself again. :)

At the end I admit I have used pv myimage.img | sudo tee /dev/sdb > /dev/null. I abandoned my right tool but pv gave me a progress bar. Unless you need to concatenate cat gives nothing. cat gives simplicity and protects you from pitfalls the cranky dd brings. For this reason alone it may be your right tool. In some cases it's my right tool.

The important thing is: whenever I use dd, cat or whatever for the task in question, it's a tool of choice, conscious choice.