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

Package:
coreutils
Source:
coreutils
Description:
GNU core utilities
Submitter:
наб
Date:
2023-05-23 21:21:03 UTC
Severity:
normal
#1036651#5
Date:
2023-05-23 19:44:56 UTC
From:
To:
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,
наб
#1036651#10
Date:
2023-05-23 21:16:42 UTC
From:
To:
https://github.com/coreutils/coreutils/commit/aa266f1b3

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

cheers,
Pádraig