GNU bug report logs - #36291
od --skip-bytes reads everything from the very beginning

Previous Next

Package: coreutils;

Reported by: Szőts Ákos <szotsaki <at> gmail.com>

Date: Wed, 19 Jun 2019 13:27:02 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36291 in the body.
You can then email your comments to 36291 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-coreutils <at> gnu.org:
bug#36291; Package coreutils. (Wed, 19 Jun 2019 13:27:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Szőts Ákos <szotsaki <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Wed, 19 Jun 2019 13:27:05 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Szőts Ákos <szotsaki <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: od --skip-bytes reads everything from the very beginning
Date: Wed, 19 Jun 2019 10:20:10 +0200
Dear List members,

I've recently discovered that od "--skip-bytes" feature doesn't
actually seek into the file but rather it reads everything from the
very beginning until the given offset is reached.

This can be problematic in two cases:
 - when speed matters, and
 - when parts of the file is read-protected (like in the case of
/dev/mem when CONFIG_STRICT_DEVMEM=y, which is usually the case). In
this example od will reach an area in /dev/mem which is read-protected
(even for root) and will report back EPERM before it could reach the
requested, and allowed, memory area. The error report will be
misleading since the resulting EPERM is not because the requested area
is protected (as suggested by the error message) but because of the
inner mechanics of the program.

In contrary, hexdump jumps to the address directly.

You can test it by running the following two commands:
- strace hexdump --skip 0xFE000124 --length 1 /dev/sda
- strace od --skip-bytes 0xFE000124 --read-bytes 1 /dev/sda

I don't know whether this behaviour is intended but if so, could you
please expand the documentation a little bit with this additional
information?

od version: od (GNU coreutils) 8.30, openSUSE Tumbleweed, x64

Thank you and all the best,

Ákos




Information forwarded to bug-coreutils <at> gnu.org:
bug#36291; Package coreutils. (Wed, 19 Jun 2019 19:43:04 GMT) Full text and rfc822 format available.

Message #8 received at 36291 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Szőts Ákos <szotsaki <at> gmail.com>, 36291 <at> debbugs.gnu.org
Subject: Re: bug#36291: od --skip-bytes reads everything from the very
 beginning
Date: Wed, 19 Jun 2019 20:42:31 +0100
On 19/06/19 09:20, Szőts Ákos wrote:
> Dear List members,
> 
> I've recently discovered that od "--skip-bytes" feature doesn't
> actually seek into the file but rather it reads everything from the
> very beginning until the given offset is reached.
> 
> This can be problematic in two cases:
>  - when speed matters, and
>  - when parts of the file is read-protected (like in the case of
> /dev/mem when CONFIG_STRICT_DEVMEM=y, which is usually the case). In
> this example od will reach an area in /dev/mem which is read-protected
> (even for root) and will report back EPERM before it could reach the
> requested, and allowed, memory area. The error report will be
> misleading since the resulting EPERM is not because the requested area
> is protected (as suggested by the error message) but because of the
> inner mechanics of the program.
> 
> In contrary, hexdump jumps to the address directly.
> 
> You can test it by running the following two commands:
> - strace hexdump --skip 0xFE000124 --length 1 /dev/sda
> - strace od --skip-bytes 0xFE000124 --read-bytes 1 /dev/sda
> 
> I don't know whether this behaviour is intended but if so, could you
> please expand the documentation a little bit with this additional
> information?
> 
> od version: od (GNU coreutils) 8.30, openSUSE Tumbleweed, x64
> 
> Thank you and all the best,

Similar issues were discussed in https://debbugs.gnu.org/18621
(though od always only skipped in regular files).

It's hard to get something applicable to all cases.
We'd like to seek for the last two here:

$ stat /proc/$$/io /sys/kernel/vmcoreinfo /dev/sda /dev/mem | grep Size
  Size: 0         	Blocks: 0          IO Block: 1024   regular empty file
  Size: 4096      	Blocks: 0          IO Block: 4096   regular file
  Size: 0         	Blocks: 0          IO Block: 4096   block special file
  Size: 0         	Blocks: 0          IO Block: 4096   character special file

Maybe we should relax the cases we do read() for,
and try to seek in block/character special files,
falling back to read() where that fails?

Note one can get the same functionality by combining dd like:
  dd bs=1 skip=$((0xFE000124)) count=1 if=/dev/sda | od
or more efficiently for larger sizes like
  dd iflag=skip_bytes skip=$((0xFE000124)) if=/dev/sda | od --read-bytes=1

cheers,
Pádraig




Reply sent to Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility. (Thu, 20 Jun 2019 01:53:01 GMT) Full text and rfc822 format available.

Notification sent to Szőts Ákos <szotsaki <at> gmail.com>:
bug acknowledged by developer. (Thu, 20 Jun 2019 01:53:02 GMT) Full text and rfc822 format available.

Message #13 received at 36291-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 36291-done <at> debbugs.gnu.org,
 Szőts Ákos <szotsaki <at> gmail.com>
Subject: Re: bug#36291: od --skip-bytes reads everything from the very
 beginning
Date: Wed, 19 Jun 2019 18:52:01 -0700
[Message part 1 (text/plain, inline)]
On 6/19/19 12:42 PM, Pádraig Brady wrote:
> Maybe we should relax the cases we do read() for,
> and try to seek in block/character special files,
> falling back to read() where that fails?

Sure, that's easy enough. I installed the attached patch and am marking 
this bug report as done.

[0001-od-use-fseek-on-non-regular-files.txt (text/plain, attachment)]

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 18 Jul 2019 11:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 5 years and 337 days ago.

Previous Next


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