bug#22624: [bug-coreutils] coreutils-8.25: big success, but problem on GNU/Hurd

[Paul Eggert]

On 02/11/2016 08:13 PM, Pádraig Brady wrote:
> The changes look good, except for this:
>
>    $ seq 1000 | split -n4
>    $ seq 100000 | split -n4
>    split: -: cannot determine file size: Illegal seek
>
> I.E. it would be better to indicate immediately
> if there is an issue determining the file size,
> because it's a gotcha that may hit users as data increases,
> and -n is complex enough anyway, that it's better to
> do as much checking up front as possible.
> I'd still disallow this case even for -n1 in case the
> number was parameterized to number of CPUs or whatever.

Hmm, well, I already spent too much time on this so I think I'll check 
in what I have (since it fixes the GNU/Hurd problem) and let it 
percolate a bit first.

I have some qualms about the approach suggested above, as it would cause 
'split' to give up on files that it currently handles (e.g., typical 
files in /proc), on the theory that we don't want to spoil users into 
thinking that 'split' can handle larger files. It'd be better to fix 
'split' to handle the larger files. It could do this for a troublesome 
case (e.g., a large /proc file) by copying the file's data into the 
first output file F1, then doing a split-in-place from F1 to the 
remaining output files F2 ... Fn (this would be done by copying to F2 
... Fn and then truncating F1). If the input file is /dev/zero, though, 
'split' should just give up right away as it does now, as there's no 
point in copying forever. Anyway, I view this as relatively low 
priority, as the troublesome cases should be quite rare in practice.

> A small point on the tests is that we use `returns_ 1 ... || fail=1`
> rather than `... && fail=1` so that we catch seg faults etc. in tests.
Thanks, I fixed that before installing the patch.