bug#80583: "dd" fails to account for short final write

Pádraig Brady <[email protected]> Wed, 11 Mar 2026 19:43:28 +0000
Newsgroups gmane.comp.gnu.core-utils.bugs
Message-ID <[email protected]>
On 11/03/2026 19:12, Paul Eggert wrote:
> On 2026-03-11 08:49, Pádraig Brady wrote:
> 
>> +(
>> +  ulimit -S -f 1024 || skip_ 'unable to set file size ulimit'
>> +  trap '' XFSZ || skip_ 'unable to ignore SIGXFSZ'
>> +  dd if=/dev/zero of=f bs=768K count=2 2>err
>> +  echo $? > dd.ret
>> +)
>> +
>> +if test "$(cat dd.ret)" = 1; then
>> +  grep -F '+1 records out' err || { cat err; fail=1; }
>> +fi
> 
> Not clear why we have to put the exit status into dd.ret; can't we just
> inspect $? after the (...) finishes?

Sure. I had some code after the dd,
but yes now the direct test would be cleaner.

> There's a problem with doing a ulimit -f in a test script: it also
> limits the size of the test trace output by the shell. Although 768K
> should be safe, better to place the limit where it actually should be,
> for safety in a subsidiary shell invocation. Something like this, perhaps?

I was aware of the side effects, but that's why I put it in a (subshell).
I'll do some more testing to verify.

>> cat <<\EOF > experr-XFSZ || framework_failure_
>> dd: error writing 'out-XFSZ': File too large
>> 2+0 records in
>> 1+1 records out

I didn't go with exact matches as
depending on POSIX mode ulimit -f can be in 512 or 1024 byte blocks.
In the former case it would be "0+1 records out".

>> EOF
>> dd ibs=2048 obs=2048 count=1 if=/dev/zero of=exp-XFSZ &&
>> ! $SHELL -c '
>>      ulimit -S -f 4 && trap "" XFSZ && \
>>      exec dd bs=1536 status=noxfer if=/dev/zero of=out-XFSZ 2>err-XFSZ
>>    ' &&
>> compare exp-XFSZ out-XFSZ &&
>> compare experr-XFSZ err-XFSZ || fail=1

cheers,
Padraig