Subject: Re: bug#79139: cp --reflink truncates sparse files on ZFS

From: Sam James <[email-masked]>
Date: Sat, 02 Aug 2025 17:47:14 +0100

Paul Eggert <[email-masked]> writes:

> On 2025-08-02 01:32, Pádraig Brady wrote:
>
>> it's worth mentioning run-time vs build-time checks. 
>
> Yes, and this could be documented more. I installed the attached.
>
>> For reference I made some notes on various version compat at:
>> http://pixelbeat/programming/linux_binary_compatibility.html
>
> I needed to use this URL:
>
> https://www.pixelbeat.org/programming/linux_binary_compatibility.html
>
>> the gnulib workaround isn't too onerous as SYS_BUFZISE_MAX is large,
>> and I expect the glibc fix will be backported to glibc 2.41 systems
>> promptly anyway.
>
> Yes, I went through similar thought processes. It didn't seem worth
> the hassle to do the extra glibc runtime checks. Gnulib has always
> used static checks for glibc versions, even in areas where this is
> serious business (e.g., malloc misbehavior). So far, nobody has
> reported an issue for this. Maybe people who build for older kernels
> (which is dubious if you ask me) aren't building for older glibcs
> (which is even more dubious).
>
> [2. text/x-patch; 0001-More-copy_file_range-commentary.patch]...

You can shorten sourceware (and gcc) bug URLs to:
https://sourceware.org/PR123456
https://gcc.gnu.org/PR123456

if that is ever useful. The changes themselves look good. Really, c_f_r
has been an API plagued with problems :(