bug#61386: [PATCH] cp,mv,install: Disable sparse copy on macOS

[Paul Eggert]

On 3/6/23 16:31, Pádraig Brady wrote:

> syntax check now looks good thanks.

You're welcome. I'm getting a failure on tests/du/threshold.sh, though, 
on Fedora 37 x86-64. Are you seeing that? See attached (compressed) log.


> I see this as a more fundamental operational thing than a limit issue.
> `split -n` needing the size up front alludes to the operation,

To ameliorate a bit, we can document this (done in the attached patch).

I don't see this as being significantly more serious than the other 
utilities that read all their input (possibly from a pipe) before 
outputting anything. They all need to deal with exhausting temporary 
space, and 'split' is merely joining the company of 'sort' and 'tac'.


> given split is often used with large data,
> explicit control is often desired over where and how it's persisted.

Anybody needing that control can copy the data themselves to a temp 
file, before calling 'split'. (Like 'sort' and 'tac'.)

Since the change doesn't invalidate existing uses, it sounds like you're 
worried that users will want 'split' to work even on enormous pipe 
inputs, inputs so large that /tmp fills up. I think this unlikely in 
practice, but if it turns into a real concern I can work around most of 
the problem by using the first output file as the temporary. However, 
I'd prefer to avoid doing this unless it's necessary, as it seems overkill.

I installed the attached patch so that 'split' uses a temp file in this 
situation, so it is no longer limited to the 128 KiB size that it was 
before the attached patch. Hope this is good enough; if not please let 
me know.

make-check-log.txt.gz
Description: application/gzip

0001-split-support-split-n-on-larger-pipe-input.patch
Description: Text Data