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
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/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.)