look(1) can't open bigfiles

Bug #510613 reported by Ralph Corderoy
This bug affects 5 people
Affects Status Importance Assigned to Milestone
bsdmainutils (Ubuntu)

Bug Description

Binary package hint: bsdmainutils

look(1) isn't passing O_LARGEFILE to open(2).

    $ dpkg -S /usr/bin/look
    bsdmainutils: /usr/bin/look
    $ dpkg-query -W bsdmainutils
    bsdmainutils 6.1.10ubuntu4
    $ echo | socat -u - file:bigfile,create,largefile,seek=100000000000
    $ ls -l bigfile
    -rw-r--r-- 1 kiosk kiosk 100000000001 2010-01-21 11:17 bigfile
    $ look foo bigfile
    look: bigfile: Value too large for defined data type
    $ strace look foo bigfile 2>&1 | grep EOVERFLOW
    open("bigfile", O_RDONLY) = -1 EOVERFLOW (Value too large for defined data type)

I've a 11.5GB sorted file and look's binary search would be ideal but I
can't use it. Once it manages to open the file, it needs to be able to
cope with the long offsets it may be seeking to.

Tags: patch
Revision history for this message
Mark Nieweglowski (lp-0) wrote :

Attached is a patch so "look" will accept files larger than INT_MAX on 64 bit architectures.

The original debian/patches/look.diff allows look.c to compile on Debian by defining SIZE_T_MAX as INT_MAX.

But it should have defined SIZE_T_MAX as SIZE_MAX.

SIZE_MAX is defined in stdint.h which wasn't included before, so this patch adds an #include <stdint.h>

stdint.h should be available on Debian since it is provided by package libc6-dev.

I just learned about "look" last week, as a utility that does a binary search on sorted files.

I tried it at work to look through a 33G log file.

Instead of grep '^2011-05-27 11:32' some.log # waiting minutes

look '2011-05-27 11:32' some.log # hoped it would be faster than grep, instead I got
look: some.log: File too large # :(

I found out about look via


and "look -b" sounds like the appropriate tool but fails unreasonably on 64 bit architectures.

Revision history for this message
Mark Nieweglowski (lp-0) wrote :

BTW: The original bug mentioned EOVERFLOW and in hindsight I see that my patch doesn't address it, but EOVERFLOW is not the bug I'm seeing. I'm seeing the max size check fail.
--- look.c:145
                if (sb.st_size > SIZE_T_MAX)
                        errx(2, "%s: %s", file, strerror(EFBIG));

$ strace look foo the.player.4.mpg 2>&1 | tail -n 7
open("the.player.4.mpg", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=4045771844, ...}) = 0
write(2, "look: "..., 6look: ) = 6
write(2, "the.player.4.mpg: File too large"..., 32the.player.4.mpg: File too large) = 32
write(2, "\n"..., 1
) = 1
exit_group(2) = ?

Revision history for this message
Ralph Corderoy (ralph-inputplus) wrote :

Hi Mark, Perhaps you're on a 64-bit machine so the behaviour differs? Anyway, could you please change this bugs status from New to Confirmed; until then, no one looks at it and it's frowned upon to Confirm one's own bugs no matter how simple and obvious the test case. :-(

Mark Nieweglowski (lp-0)
Changed in bsdmainutils (Ubuntu):
status: New → Confirmed
tags: added: patch
Revision history for this message
Mark Nieweglowski (lp-0) wrote :

This patch defines _LARGEFILE64_SOURCE and _FILE_OFFSET_BITS so fstat and mmap become fstat64 and mmap64.

It replaces the previous patch and is meant to replace the package's debian/patches/look.diff

Revision history for this message
Mark Nieweglowski (lp-0) wrote :

Sorry about the noise. I attached the wrong patch last time.

Revision history for this message
Jürgen Gmach (jugmac00) wrote :

Is there any chance this gets fixed?

8 years later I still get the bug on Ubtunu 18.04 / WSL.

jugmac00@DESKTOP-jugmac00:/mnt/d/Projects/pw-hash$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04 LTS
Release: 18.04
Codename: bionic

jugmac00@DESKTOP-jugmac00:/mnt/d/Projects/pw-hash$ look -f $(echo -n xxx| sha1sum | awk '{print $1}') pwned-passwords-sha1-ordered-by-hash-v4.txt
look: pwned-passwords-sha1-ordered-by-hash-v4.txt: File too large

Revision history for this message
Stuart Taylor (stuartraetaylor) wrote :

It would be great to see this fixed in an upcoming release of Ubuntu.

I had the same problem and applied Mark Nieweglowski's fix here - https://github.com/stuartraetaylor/bsdmainutils-look

$ ./look -bf $(echo -n "P@ssw0rd" | sha1sum | cut -d' ' -f1) pwned-passwords-sha1-ordered-by-hash-v4.txt

There's also an alternative approach here - https://www.tablix.org/~avian/blog/archives/2018/10/checking_passwords_against_haveibeenpwned_com/

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers