bug#7362: dd strangeness

[Pádraig Brady]

On 01/03/11 09:50, Paul Eggert wrote:
> On 02/28/2011 01:41 AM, Pádraig Brady wrote:
>> Hmm, it's better to be explicit but I think defaulting to "fullblock"
>> is too risky. As an interim step at least, how about just warning
>> as per the attached.
> 
> Ouch.  This is a pain to think about.  But here are some thoughts anyway:
> 
>  * I went back and reread POSIX, and "dd" is allowed to issue
>    diagnostics to stderr whenever it likes.  So we don't need to
>    worry about POSIXLY_CORRECT if all we want to do is issue diagnostics.
>    We can issue them regardless of POSIXLY_CORRECT.

Checking POSIXLY_CORRECT allows one to disable the warnings

> 
>  * I don't understand the business with C_SYNC.  People who use
>    conv=sync know what they're doing, or ought to; there's little
>    point giving them a warning.

They might think the short read might only apply to the end of the input?
But fair enough, it's not as important as the O_DIRECT issue.

>  * For (O_DIRECT | O_CIO), surely this matters only for output_flags.
>    If these bits are set in input_flags then O_FULLBLOCK is irrelevant, no?

True.

>  * If we care about max_records we should also care about skip_records,
>    since short reads matter when skipping in a pipe, too.

True.

>  * Since POSIX doesn't specify the direct or cio flags, we're free
>    to have them silently enable iflag=fullblock.  But it doesn't sound
>    right to do that.  Instead, we should set conversions_mask |= C_TWOBUFS,
>    because the input and output blocksizes might differ.
> 
>  * If we suggest ibs=whatever rather than iflag=fullblock, our
>    suggestions will be portable to other POSIX implementations, which
>    is a plus.

So the standard way to accumulate short reads to a full write,
is to specify separate ibs and obs (we'd probably want to prompt about
setting obs too for efficiency). However I think that would mess up
with a specific count (1 for each partial read) or with conv=sync,noerror

> 
>  * Rather than warn about potential problems, how about diagnosing the
>    problems only when they actually occur?  That would help us avoid
>    crying wolf.

I like that idea, except that users might only hit an issue
on particular runs, or when moving from a test file
to a pipe in production.

cheers,
Pádraig.