This happened with coreutils 8.13 on Fedora 14 x86-64 (coreutils compiled with GCC 4.6.1). I interrupted 'dd' with control-C, but it didn't respond right away; instead, it churned away and created the entire output file, issuing a bogus diagnostic about the input file. Here's the transcript:
$ dd if=/dev/zero of=$HOME/junk/zero bs=1024 count=1000000 ^C1000000+0 records in 1000000+0 records out 1024000000 bytes (1.0 GB) copied, 20.1583 s, 50.8 MB/s dd: closing input file `/dev/zero': Bad file descriptor $ ls -l zero -rw-r--r-- 1 eggert eggert 1024000000 Sep 27 12:18 zero The problem with the diagnostic is intermittent. It usually does not happen. Usually, there's simply an unconscionably long wait between the time I type ^C and the time that dd exits, e.g.: $ dd if=/dev/zero of=zero bs=1024 count=1000000 ^C487034+0 records in 487034+0 records out 498722816 bytes (499 MB) copied, 11.6897 s, 42.7 MB/s (here I waited about 10 seconds between the time I typed ^C and the time that dd exited). The filesystem is ext4 atop md (RAID-1). The same problem occurs with /bin/dd (coreutils 8.5) so if it is a coreutils bug it's not a new one. Don't have time to debug this right now but thought I'd get a bug report into the system. Quite possibly it is not a coreutils bug at all, but a kernel bug, but in that case where do I report it? to a Fedora mailing list?
