GNU bug report logs -
#13391
dd silently ignores lseek error
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#13391: dd silently ignores lseek error
which was filed against the coreutils package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 13391 <at> debbugs.gnu.org.
--
13391: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13391
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (text/plain, inline)]
On 01/08/2013 08:55 PM, Paul Eggert wrote:
> On 01/08/13 10:11, Neil Klopfenstein wrote:
>> Note that it begins reading at the _beginning of the ar file_ -- the 'skip'
>> argument has failed silently.
>
> But the 'skip' hasn't failed. It's merely being implemented via 'read'
> rather than via 'lseek'. The records are being skipped correctly.
>
> It might be useful to give dd a new option, which causes it
> to insist on lseeking rather than reading in cases like these,
> and to report an error if the lseek fails.
I had a look around for a tool to verify
that a file/device supports the seek operation
and couldn't find one.
So this seems like useful functionality.
Worth applying the attached?
thanks,
Pádraig.
[dd-flag-seekable.diff (text/x-patch, attachment)]
[Message part 5 (message/rfc822, inline)]
[Message part 6 (text/plain, inline)]
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
[Message part 7 (text/html, inline)]
This bug report was last modified 12 years and 132 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.