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
