Re: dd block size deficiency (bug or feature ?)

[Jim Meyering]

Oskar Schirmer <address@hidden> wrote:
> we are using the dd command on a gnu/linux box (kernel 2.4.21 something)
> as follows, to generate a specific flash prom image with
> defined length (8*21 kbyte):
>
> $ cat bigfile | dd of=/tmp/xyz bs=8k count=21

Thanks for the report.

Can you still reproduce the problem if you give dd
the input directly rather than through a pipe?

  dd of=/tmp/xyz bs=8k count=21 < bigfile
or
  dd of=/tmp/xyz bs=8k count=21 if=bigfile

...
> but, on rare occasions, it says something like:
> 19+2 records in
> 19+2 records out
> $ ls -l /tmp/xyz
> -rw-r-----    1 oschirm  emlix      160060 Jun 17 11:17 xyz
...
> Having a closer look to the coreutils sources, we found that in
> src/dd.c the function "safe_read" is used to read blocks, while
> for writing "full_write" is used. Provided we understood it right,
> "safe_read" does a single device access attempt, while "full_read"
> would reattempt to receive more data, when the first read was short.
>
> Question 1:
>   should dd.c use "full_read" instead of "safe_read" ?

No.  dd must detect partial reads and pad accordingly (as specified
by other options).

> We are aware, that dd is historically used for tape/disk access etc,
> where block sizes and "short block results" might be a feature, so
> maybe old software might break, when dd is changed here.

Exactly.

> On the other hand, we cant see how decisions were taken, when
> to use "safe_read" and when to use "full_read".
>
> Question 2:
>   should other tools in coreutils use "full_read" instead of "safe_read" ?
>   It seems, that "safe_write" is no longer used, in favor of "full_write".

I expect that replacing any safe_read with full_read will cause
problems in some cases.  But if you find a case in which you think
full_read would be better, please report it to this list.
Of course, you should first test your change and as a minimum,
ensure that `make check' still passes all of its tests.