this is actually a regression in Android V, since the change to enable
the use of copy_file_range(2) went in too late for U, so i'm sending
this minimal fix that i can cherrypick to Android V (since regular
AOSP changes won't make it to V at this point).
that said... there's a separate cosmetic issue i noticed while testing:
```
/tmp/x$ ~/toybox-tar/toybox tar xvf ~/toybox-tar/x/x.tar
tar: tar: had errors
two
two-and-a-half
/tmp/x$ ls -l
total 4657156
-rw-r----- 1 enh primarygroup 2147483648 Jul 31 15:44 two
-rw-r----- 1 enh primarygroup 2621441024 Jul 31 15:45 two-and-a-half
```
from the
```
error:
if (fd!=1) perror_msg(0);
skippy(TT.hdr.size-used);
```
code in tar.c's sendfile_sparse() that's probably worth a separate fix.
On Wed, Jul 31, 2024 at 4:04 PM enh <e...@google.com> wrote:
>
> We want to check whether the next call we make will try to send more
> than 1<<30 bytes, not whether the total number of bytes to transfer is
> more than that.
>
> Interestingly, the read() fallback implementation already has the right
> check, presumably because files larger than libbuf are commonplace,
> whereas files larger than 1<<30 bytes are not.
>
> Tested locally using truncate to create a 2GiB file (which works) and a
> 2.5GiB file (which does not work), tar to create the tarfile, and then
> tar to extract them.
> ---
> lib/portability.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
_______________________________________________
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
