#13391 - dd silently ignores lseek error (original) (raw)

GNU bug report logs - #13391

dd silently ignores lseek error

Previous Next

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? [...]

[...] /* else file_size && offset > OFF_T_MAX or file ! seekable */

   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?

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);

+"), stdout);

no line break needed here.

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

leek?

(usage): Describe the new flag.

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 120 days ago.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.