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
