dd: seek=0 still seeks, erroring on non-seekable files

[ijwhitfield]

Hi!

The Linux kernel selftest for ftrace:trace_marker_raw is failing on Ubuntu 26.04 because of a parity issue in dd between rust coreutils and GNU coreutils. A call to dd was added to the Linux test in this commit, and the output file is trace_marker_raw, which notably does not support seeking. With GNU dd, this test passes, and with uutils dd the test hangs until timeout.

I believe this to be because of a few spots where dd unconditionally seeks, and errors from non-seekable files are not handled. Here's a minimal reproducer for a system with dd pointing to the GNU binary:

#!/bin/sh
echo "GNU:"
echo hello | dd of=/sys/kernel/tracing/trace_marker_raw
echo "uutils:"
echo hello | coreutils/target/debug/coreutils dd of=/sys/kernel/tracing/trace_marker_raw

which outputs:

GNU:
0+1 records in
0+1 records out
6 bytes copied, 2.6711e-05 s, 225 kB/s
uutils:
dd: failed to seek in output file: Illegal seek

[markzyu]

Can confirm this happens for non-seekable output files.

Also, for non-seekable input files, we are missing an error message. (Edit: I will ignore this second part because this issue seems to be more related to non-seekable output files)

[sfeirc]

Hi! I’d like to work on this issue. From my initial investigation, dd appears to perform an output seek even when the requested offset is zero. My plan is to add a regression test using a non-seekable output and then avoid the seek when the offset is zero, while leaving non-zero seek behavior unchanged. Does this approach sound appropriate?

[markzyu]

Please, go ahead. I'm just a hobbyist.

[ijwhitfield]

The highest priority for me is being able to use uutils dd at all with non-seekable output files, so I agree seek!=0 behavior would probably be scope creep.

It may be worth also requesting additional testing in a follow-up issue to confirm behavior compatibility with GNU in other use cases of non-seekable files, like as the input file or when seek!=0. It could be a blind spot for the project currently.

[sfeirc]

Hi! I noticed that this PR is already implementing the fix for #14696. Since you said I could go ahead, would you prefer that I help find and add a portable regression test to this PR, or are you planning to continue it yourself? I’d like to avoid duplicating the work.

[markzyu]

If this is about PR #14735, I suspected that it might be impossible to write a regression test using only new_ucmd because it requires access to actual files. And my current PR reviews suggested that I should not add tests in the src/uu/dd/src/dd.rs file. I do not know of a way around this without adding tests directly to src/uu/dd/src/dd.rs.

The reviewers had not replied on #14735 for some time. I consider it abandoned and would close this PR if you have a new one.