Debian Bug report logs - #1036651
coreutils: split: -n <digit> with (some?) devices fails with EOVERFLOW, accepts some chardevs?

Reply or subscribe to this bug.

Display info messages

Message #5 received at [email protected] (full text, mbox, reply):

From: наб <[email protected]>

To: Debian Bug Tracking System <[email protected]>

Subject: coreutils: split: -n <digit> with (some?) devices fails with EOVERFLOW, accepts some chardevs?

Date: Tue, 23 May 2023 21:44:56 +0200

[Message part 1 (text/plain, inline)]

Package: coreutils
Version: 9.1-1
Version: 8.32-4+b1
Severity: normal

Dear Maintainer,

This happens regardless of the blockdev size:
  $ split -n20 /dev/loop2
  split: /dev/loop2: cannot determine file size: Value too large for defined data type
and with 
  $ split -n3 /dev/full
  split: /dev/full: cannot determine file size: Value too large for defined data type
the normal message is
  $ cat | split -n20
  split: -: cannot determine file size
i.e. w/o strerror.
Nothing's EOVERFLOW-worthy here, one'd think.

However:
  $ split -n20
  split: -: cannot determine file size
  $ split -n20 /dev/pts/0
  split: /dev/pts/0: cannot determine file size
  $ split -n20 /dev/full
  split: /dev/full: cannot determine file size: Value too large for defined data type
  $ split -n20 /dev/zero
  split: /dev/zero: cannot determine file size: Value too large for defined data type
  $ split -n20 /dev/rfkill
  split: /dev/rfkill: cannot determine file size
so normal unseekable files get no strerror,
/dev/full and /dev/zero are seekable and somehow yield EOVERFLOWs as well.

Oddly:
  $ split -n20 /dev/autofs
  split: /dev/autofs: cannot determine file size: Invalid argument
but /dev/autofs is seekable, and only EINVALs on read()s.

Also oddly:
  $ split -n20 /dev/null
just works.
Is it hard-coded somehow? This isn't noted in the manual.

Best,
наб

-- System Information:
Debian Release: 12.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: x32 (x86_64)
Foreign Architectures: amd64, i386

Kernel: Linux 6.1.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages coreutils depends on:
ii  libacl1      2.3.1-3
ii  libattr1     1:2.5.1-4
ii  libc6        2.36-9
ii  libgmp10     2:6.2.1+dfsg1-1.1
ii  libselinux1  3.4-1+b5

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

[signature.asc (application/pgp-signature, inline)]

Message #10 received at [email protected] (full text, mbox, reply):

From: Pádraig Brady <[email protected]>

To: наб <[email protected]>, [email protected]

Subject: Re: Bug#1036651: coreutils: split: -n <digit> with (some?) devices fails with EOVERFLOW, accepts some chardevs?

Date: Tue, 23 May 2023 22:16:42 +0100

On 23/05/2023 20:44, наб wrote:
> Package: coreutils
> Version: 9.1-1
> Version: 8.32-4+b1
> Severity: normal
> 
> Dear Maintainer,
> 
> This happens regardless of the blockdev size:
>    $ split -n20 /dev/loop2
>    split: /dev/loop2: cannot determine file size: Value too large for defined data type
> and with
>    $ split -n3 /dev/full
>    split: /dev/full: cannot determine file size: Value too large for defined data type
> the normal message is
>    $ cat | split -n20
>    split: -: cannot determine file size
> i.e. w/o strerror.
> Nothing's EOVERFLOW-worthy here, one'd think.
> 
> However:
>    $ split -n20
>    split: -: cannot determine file size
>    $ split -n20 /dev/pts/0
>    split: /dev/pts/0: cannot determine file size
>    $ split -n20 /dev/full
>    split: /dev/full: cannot determine file size: Value too large for defined data type
>    $ split -n20 /dev/zero
>    split: /dev/zero: cannot determine file size: Value too large for defined data type
>    $ split -n20 /dev/rfkill
>    split: /dev/rfkill: cannot determine file size
> so normal unseekable files get no strerror,
> /dev/full and /dev/zero are seekable and somehow yield EOVERFLOWs as well.
> 
> Oddly:
>    $ split -n20 /dev/autofs
>    split: /dev/autofs: cannot determine file size: Invalid argument
> but /dev/autofs is seekable, and only EINVALs on read()s.
> 
> Also oddly:
>    $ split -n20 /dev/null
> just works.
> Is it hard-coded somehow? This isn't noted in the manual.

This has all changed in coreutils 9.2 with:
https://github.com/coreutils/coreutils/commit/aa266f1b3

That causes data to be read, rather than depending on lseek.

cheers,
Pádraig

Send a report that this bug log contains spam.