#13391 - dd silently ignores lseek error (original) (raw)
GNU bug report logs - #13391
dd silently ignores lseek error
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13391 in the body.
You can then email your comments to 13391 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwardedto bug-coreutils <at> gnu.org
:bug#13391
; Package coreutils
. (Tue, 08 Jan 2013 18:24:02 GMT) Full text and rfc822 format available.
Acknowledgement sentto Neil Klopfenstein <neil.klopfenstein <at> gmail.com>
:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org
. (Tue, 08 Jan 2013 18:24:02 GMT) Full text and rfc822 format available.
Message #5 received at submit debbugs.gnu.org (full text, mbox):
[Message part 1 (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, "!\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 2 (text/html, inline)]
Information forwardedto bug-coreutils <at> gnu.org
:bug#13391
; Package coreutils
. (Tue, 08 Jan 2013 20:56:02 GMT) Full text and rfc822 format available.
Message #8 received at 13391 debbugs.gnu.org (full text, mbox):
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.
Reply sentto Pádraig Brady <P <at> draigBrady.com>
:
You have taken responsibility. (Wed, 09 Jan 2013 01:15:01 GMT) Full text and rfc822 format available.
Notification sentto Neil Klopfenstein <neil.klopfenstein <at> gmail.com>
:
bug acknowledged by developer. (Wed, 09 Jan 2013 01:15:02 GMT) Full text and rfc822 format available.
Message #13 received at 13391-done debbugs.gnu.org (full text, mbox):
[Message part 1 (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)]
Information forwardedto bug-coreutils <at> gnu.org
:bug#13391
; Package coreutils
. (Wed, 09 Jan 2013 04:59:02 GMT) Full text and rfc822 format available.
Message #16 received at 13391-done debbugs.gnu.org (full text, mbox):
On 01/08/2013 05:14 PM, Pádraig Brady wrote:
Worth applying the attached?
Looks good, except I would avoid calling lseek on STDOUT_FILENO unless oflag=seekable is set. Just being conservative: the effect of lseek on unseekable files is implementation-defined.
Information forwardedto bug-coreutils <at> gnu.org
:bug#13391
; Package coreutils
. (Wed, 09 Jan 2013 07:25:02 GMT) Full text and rfc822 format available.
Message #19 received at 13391 debbugs.gnu.org (full text, mbox):
Hi,
On Wed, Jan 09, 2013 at 01:14:22AM +0000, Pádraig Brady wrote:
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? [...]
- src/dd.c: Add the new O_SEEKABLE flag. (main): Verify leek() works if O_SEEKABLE is set. ^^^^^^lseek()
[...] /* else file_size && offset > OFF_T_MAX or file ! seekable */
- Stray new newline?
do
[...]
Besides these nitpicks the patch looks good to me.
HTH, Erik
Information forwardedto bug-coreutils <at> gnu.org
:bug#13391
; Package coreutils
. (Wed, 09 Jan 2013 07:37:02 GMT) Full text and rfc822 format available.
Message #22 received at 13391 debbugs.gnu.org (full text, mbox):
On 01/09/2013 02:14 AM, Pádraig Brady wrote:
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?
- cfg.mk (sc_dd_O_FLAGS): Add O_SEEKABLE to the list of private flags with a a single underscore.
s/a a/a/
@@ -619,6 +628,9 @@ Each FLAG symbol may be:\n
if (O_SEEK_BYTES) fputs (_(" seek_bytes treat 'seek=N' as a byte count (oflag only)\n
"), stdout);
if (O_SEEKABLE)
fputs (_(" seekable fail unless seekable\n\
+"), stdout);
no line break needed here.
- offset = lseek (STDOUT_FILENO, 0, SEEK_CUR);
- output_seekable = (0 <= offset);
- if (! input_seekable && (input_flags & O_SEEKABLE))
- {
error (EXIT_FAILURE, input_seek_errno, _("input is not seekable %s"),
quote (input_file));
- }
why not check input_seekable where it is set - ~60 lines above?
Have a nice day, Berny
Information forwardedto bug-coreutils <at> gnu.org
:bug#13391
; Package coreutils
. (Wed, 09 Jan 2013 08:28:02 GMT) Full text and rfc822 format available.
Message #25 received at 13391 debbugs.gnu.org (full text, mbox):
From ea524ab7388bb35e591dcdb0fc7f7989d61143ae Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1draig=20Brady?= <P draigBrady.com> Date: Wed, 9 Jan 2013 00:42:38 +0000 Subject: [PATCH] dd: add [io]flag=seekable to verify file support for lseek
- src/dd.c: Add the new O_SEEKABLE flag. (main): Verify leek() works if O_SEEKABLE is set.
leek?
(usage): Describe the new flag.
- tests/dd/misc.sh: Augment the test for the new options.
- doc/coreutils.texi (dd invocation): Describe the new option.
- cfg.mk (sc_dd_O_FLAGS): Add O_SEEKABLE to the list of private flags with a a single underscore.
- NEWS: Mention the new feature.
Information forwardedto bug-coreutils <at> gnu.org
:bug#13391
; Package coreutils
. (Wed, 09 Jan 2013 10:10:02 GMT) Full text and rfc822 format available.
Message #28 received at 13391 debbugs.gnu.org (full text, mbox):
On 01/09/2013 07:36 AM, Bernhard Voelker wrote:
why not check input_seekable where it is set - ~60 lines above?
I was trying to keep related code together.
Thanks for all the reviews, which I've fixed locally.
To provide an argument for why this shouldn't go in, the following is equivalent:
python -c 'import os; os.lseek(0,0,os.SEEK_CUR)' 2>/dev/null < /the/file && dd if=/the/file ...
So if the need is esoteric enough the above might suffice?
I'll leave it stew for a while longer.
thanks, Pádraig.
Information forwardedto bug-coreutils <at> gnu.org
:bug#13391
; Package coreutils
. (Thu, 17 Jan 2013 11:58:01 GMT) Full text and rfc822 format available.
Message #31 received at 13391 debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 01/09/2013 10:08 AM, Pádraig Brady wrote:
On 01/09/2013 07:36 AM, Bernhard Voelker wrote:
why not check input_seekable where it is set - ~60 lines above?
I was trying to keep related code together.
Thanks for all the reviews, which I've fixed locally.
To provide an argument for why this shouldn't go in, the following is equivalent:
python -c 'import os; os.lseek(0,0,os.SEEK_CUR)' 2>/dev/null < /the/file && dd if=/the/file ...
So if the need is esoteric enough the above might suffice?
I'll leave it stew for a while longer.
I'm still 50:50 give the above, so I'll not push until I get more positive feedback. The latest is attached for reference.
thanks, Pádraig.
[dd-seekable.diff (text/x-patch, attachment)]
**bug archived.**Request was from Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org
. (Thu, 14 Feb 2013 12:24:04 GMT) Full text and rfc822 format available.
This bug report was last modified 12 years and 119 days ago.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.