bug#13391: dd silently ignores lseek error

[Neil Klopfenstein]

Hi all,

While trying to diagnose a weird filesystem bug, I found an error in GNU dd
v8.12.

The weird bug is causing lseek() to fail improperly. That's not the problem
I'm reporting, though. I was trying to use dd to demonstrate the lseek
error to my sysadmin. Instead, I found that dd is ignoring the lseek
failure.

Here is the relevant strace output:
$ strace dd if=libdvapp-O.a of=/dev/null bs=33k skip=1
...
open("libdvapp-O.a", O_RDONLY) = 3
dup2(3, 0)                              = 0
close(3)                                = 0
lseek(0, 0, SEEK_CUR)                   = 0
open("/dev/null", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
dup2(3, 1)                              = 1
close(3)                                = 0
clock_gettime(CLOCK_MONOTONIC, {12951065, 389531862}) = 0
ioctl(0, MGSL_IOCSTXIDLE or MTIOCGET or SNDCTL_MIDI_MPUCMD, 0x7fbfffe3f0) =
-1 ENOTTY (Inappropriate ioctl for device)
lseek(0, 33792, SEEK_CUR)               = -1 EINVAL (Invalid argument)
 ^ this is the syscall which should not be failing
ioctl(0, MGSL_IOCSTXIDLE or MTIOCGET or SNDCTL_MIDI_MPUCMD, 0x7fbfffe3f0) =
-1 ENOTTY (Inappropriate ioctl for device)
lseek(0, 0, SEEK_END)                   = -1 EINVAL (Invalid argument)
read(0, "!<arch>\n/               13576110"..., 33792) = 33792
...

Note that it begins reading at the _beginning of the ar file_ -- the 'skip'
argument has failed silently. The output of dd does not indicate any error:

3+1 records in
3+1 records out
103310 bytes (103 kB) copied, 0.000375 s, 275 MB/s

Expected behavior: dd should pass on any unexpected errors reported by
system calls.

I realize this is an old version of coreutils but I don't have a newer
version available to test against the anomaly. Sorry if it's already been
fixed.

Regards,
--Neil