0

Working on both Linux and OS X (10.10.5), I'm using the command line tool dd to copy the contents of a USB flash drive to and from a compressed archive. To create the archive, I use the following on an unmounted drive (on Linux the format is something like /dev/sdb; on OS X it's something like /dev/disk2):

sudo dd if=/dev/disk1 bs=1m | gzip -c > disk.image.gz

which copies the entire drive's contents, compresses it, and then writes it to disk.image.gz. To unpack the image into a new drive, I use:

cat disk.image.gz | gunzip -c | sudo dd of=/dev/disk1 bs=1m

which takes the compressed disk image, uncompresses it, and then writes it to the drive. (You can check the progress of either command by executing the following in a separate window on Linux:

sudo killall -USR1 dd

or on OS X:

sudo killall -INFO dd

which in both cases signals dd to output a couple of lines on the amount of data transferred.)

Both processes work well on Linux. However, although the reading and compression work well on OS X, the decompression and writing never terminates. dd keeps writing data and more data, even though the (decompressed) source file has ended, and the disk drive should be full. If I wait until more data has written than should fit on the flash drive, and then ^C to terminate the command, the resulting drive seems to mount and operate just fine. But, it worries me that the behavior isn't what I expect.

Any idea why dd's writing never terminates, even though it is no longer receiving data?

(BTW: if you're using this as instructions to burn your own disk drives, MAKE SURE you have the right device identifiers (e.g. the /dev/sdb or /dev/disk2 mentioned above). dd does exactly what you tell it to do, so if you get the wrong identifier and tell it to overwrite your boot drive, it'll happily do so. Look elsewhere on how to determine the right device.)

  • 1
    Are you sure you have your drive identifiers correct? On OS X, they are /dev/disk1, /dev/disk2, etc. – Allan Apr 5 '17 at 13:31
  • Yes; my examples used the Linux identifiers, but on OS X I used /dev/disk2 (checking thrice so I didn't trash my boot drive). I'll clarify in the question. – Daniel Griscom Apr 5 '17 at 14:17
  • @DanielGriscom You might want to use cp instead of dd if you do not have special needs and just want to copy the contents of a block device. – Max Ried Apr 5 '17 at 14:29
  • @DanielGriscom Or cat if you want to pipe it somewhere. – Max Ried Apr 5 '17 at 14:30
  • @DanielGriscom Besides: You should use rdisk devices for those actions: superuser.com/questions/631592/… – Max Ried Apr 5 '17 at 14:44
1

This might not really answer the question, but might provide a solution.

Instead of using dd which seems to behave oddly for you, just use cat or cp. At least on OS X, they work very well on block devices. So:

sudo dd if=/dev/disk1 bs=1m | gzip -c > disk.image.gz

becomes

sudo cat /dev/disk1 | gzip -c > disk.image.gz


If you want the reverse, just redirect gunzip's output:

cat disk.image.gz | gunzip -c | sudo dd of=/dev/disk1 bs=1m

becomes

gunzip -c disk.image.gz | sudo tee /dev/disk1 > /dev/null

If you just want to copy a block device

sudo dd if=/dev/disk1 of=disk.image bs=1m

becomes

sudo cp /dev/disk1 disk.image

If you just want to copy an image to a block device (e.g. Raspbian to SD card)

sudo dd if=disk.image of=/dev/disk1 bs=1m

becomes

sudo cp disk.image /dev/disk1

This also prevents any hassle with block sizes.

  • I just tried the above gunzip -c disk.image.gz | sudo tee /dev/disk1 > /dev/null twice. It failed once (continuing far longer than expected; I couldn't measure the data transferred because I wasn't using dd), and succeeded once. Looks like something else is going on. – Daniel Griscom Apr 6 '17 at 0:15
  • @DanielGriscom There is an open source project named progress, previously named cv that displays the progress of a lot of utilities. You might want to try this. – Max Ried Apr 6 '17 at 7:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .