Subject: bug#63850: closed (Re: bug#63850: cp fails for files > 2 GB if copy offload is unsupported)

From: [email-masked] (GNU bug Tracking System)
Date: Wed, 07 Jun 2023 19:14:02 +0000

Your bug report

#63850: cp fails for files > 2 GB if copy offload is unsupported

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
63850: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63850
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#63850: cp fails for files > 2 GB if copy offload is unsupported
From: Paul Eggert <[email-masked]>
To: Sam James <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: Wed, 7 Jun 2023 12:13:28 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

On 2023-06-06 03:02, Sam James wrote:
> Thanks Paul. Do you know if there's any other cases of this in gnulib?

There's no other use of linux/version.h in Gnulib. However, this doesn't 
mean there are no other instances of the problem, as it's common to 
assume that you'll run on a host no older than the build host. Every use 
of Autoconf macros like AC_RUN_IFELSE assume this sort of thing, and I 
would not be surprised if there are other examples of this more-general 
problem when some builders (unwisely) build apps intended to run on 
platforms older than the build platform. (For what it's worth, I count 
331 uses of AC_RUN_IFELSE in Gnulib; it'd be a pain to audit them all.)

It's OK to build glibc for Linux kernels somewhat older than the build 
kernel, since glibc explicitly exports that. But it's not OK to build 
other packages that way, since they don't support it. You'll get away 
with it in many cases, but when it doesn't work then the problem is on 
the builder, not on the packages being built.

> (or whether, by chance, if you know off the top of your head if any
> other gnulib consumers definitely use copy_file_range?)

Other coreutils programs like 'install' use copy_file_range.

Emacs uses it. I just now installed the following patch into 
bleeding-edge Emacs to work around the problem, by updating to current 
Gnulib. This workaround should appear in Emacs 30, whenever that happens 
(not for a year or two I'd think, as Emacs 29 isn't out yet).

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a902156068ab071f93cc9bbd34cd320919b74064

PS. I'm boldly marking the coreutils bug as fixed.

Subject: cp fails for files > 2 GB if copy offload is unsupported
From: Sam James <[email-masked]>
To: <[email-masked]>
Date: Fri, 02 Jun 2023 16:44:57 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

Hello,

Forwarding a downstream report of a behaviour change between
coreutils-9.1 and coreutils-9.3 from https://bugs.gentoo.org/907474.

The reporter bisected it to 093a8b4bfaba60005f14493ce7ef11ed665a0176
("copy: fix --reflink=auto to fallback in more cases", see bug#62404)
and gave strace output showing:
```
fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
copy_file_range(3, NULL, 4, NULL, 9223372035781033984, 0) = 2147479552
copy_file_range(3, NULL, 4, NULL, 9223372035781033984, 0) = -1 EINVAL
(Invalid argument)
```

"""
When I try to copy a large file (> 2 GB) like so:

cp --debug file_a file_b

output looks like this:

'file_a' -> 'file_b'
cp: error copying 'file_a' to 'file_b': Invalid argument
copy offload: unsupported, reflink: unsupported, sparse detection: no

Afterwards file_b has a size of 2147479552 bytes (= 2G - 4K).

On another system (with newer kernel version) it looks like this:

cp --debug file_a file_b
'file_a' -> 'file_b'
copy offload: yes, reflink: unsupported, sparse detection: no
"""

Let me know if you need further information, although there's
some more on the downstream Gentoo bug I linked.

Apparently this is only happening w/ the 4.19.x kernels.

Thanks!