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

[Sam James]

Paul Eggert <eggert@cs.ucla.edu> writes:

> 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.

I don't see how this is compatible with what I explained, given you
can't have parallel linux-headers installs.

Nobody uses glibc in a vacuum, either, so it's not particularly
meaningful to say you can use glibc but nothing else in that way.

If you object to this, please bring it up on the glibc mailing list
to discuss revising the guidance. But again, I genuinely don't see
how anything other than the status quo could work. We can't enforce
what kernels users are running, and we can't simultaneously make the
users install the headers for the kernel they just built manually while
also having things owned and controlled by the package manager.

We're also very much not the only distribution doing this - Arch
usually ships the latest linux-headers, and Alpine does as well.
And we've done it for years with very, very few issues.

>
>
>> (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
>

Thanks!

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

Works for me, thanks.

signature.asc
Description: PGP signature