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

From: Collin Funk <[email-masked]>
Date: Fri, 01 Aug 2025 21:39:44 -0700

Bruno Haible <[email-masked]> writes:

>> +      /* Work around glibc bug 33245
>
> It would be good to document the workaround in
> doc/glibc-functions/copy_file_range.texi.

Yep, I noticed as well. Just wanted to make sure I wasn't
misunderstanding the versions before doing it myself. Done with the
attached patch now.

> Collin Funk wrote:
>> Can't we make this condition only occur for glibc 2.41 and glibc 2.42?
>> The issue shouldn't occur before commit
>> 89b53077d2a58f00e7debdfe58afabe953dac60d in glibc (2024-06-25).
>
> Users are supposed to be able to create binaries with an older version of
> glibc, then upgrade their glibc. The binaries should continue to work.

Right. I seemed to have forgot that every program isn't statically
linked to glibc... Thanks.

Collin

>From c3779ad180fe169868f65d7eb6204fe62af33b80 Mon Sep 17 00:00:00 2001
Message-ID: <c377[email-masked]>
From: Collin Funk <[email-masked]>
Date: Fri, 1 Aug 2025 21:34:37 -0700
Subject: [PATCH] doc: Mention the copy_file_range bug.

* doc/glibc-functions/copy_file_range.texi: Mention glibc bug 33245 in
version 2.41 and 2.42.
---
 ChangeLog                                | 6 ++++++
 doc/glibc-functions/copy_file_range.texi | 5 +++++
 2 files changed, 11 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index e60a387611..370aefef3f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2025-08-01  Collin Funk  <[email-masked]>
+
+	doc: Mention the copy_file_range bug.
+	* doc/glibc-functions/copy_file_range.texi: Mention glibc bug 33245 in
+	version 2.41 and 2.42.
+
 2025-08-01  Paul Eggert  <[email-masked]>
 
 	copy-file-range: work around glibc bug 33245
diff --git a/doc/glibc-functions/copy_file_range.texi b/doc/glibc-functions/copy_file_range.texi
index 0878fd50fc..2b0ac85ee5 100644
--- a/doc/glibc-functions/copy_file_range.texi
+++ b/doc/glibc-functions/copy_file_range.texi
@@ -31,6 +31,11 @@ @node copy_file_range
 On these kernel versions, the replacement function always fails with
 error @code{ENOSYS}.
 
+@item
+@c https://sourceware.org/bugzilla/show_bug.cgi?id=33245
+This function returns an incorrect value when the number of bytes copied
+exceeds @code{INT_MAX} on systems using glibc version 2.41 or 2.42.
+
 @item
 This function is provided on GNU/Hurd but it is only a stub: It always
 fails with error @code{ENOSYS}.
-- 
2.50.1