GNU bug report logs - #63850
cp fails for files > 2 GB if copy offload is unsupported

Previous Next

Full log

Message #53 received at 63850 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Sam James <sam <at> gentoo.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 63850 <at> debbugs.gnu.org, floppym <at> gentoo.org
Subject: Re: bug#63850: cp fails for files > 2 GB if copy offload is
 unsupported
Date: Tue, 6 Jun 2023 11:27:13 +0100

On 06/06/2023 11:02, Sam James wrote:
> 
> Paul Eggert <eggert <at> cs.ucla.edu> writes:
> 
>> On 2023-06-05 22:26, Sam James wrote:
>>> It's just that linux-headers is
>>> a special case
>>
>> Indeed it is. And apparently glibc avoids the copy_file_range bugs by
>> never, ever using copy_file_range internally - which explains why
>> glibc hasn't run into this backward compatibility issue. Presumably
>> once glibc starts assuming kernel 5.3 or later, it can start using
>> copy_file_range internally.
>>
>> Anyway, thanks for explaining. I installed the patch I mentioned into
>> Gnulib and have updated coreutils accordingly on Savannah
>> master. Please give it a try.
> 
> Thanks Paul. Do you know if there's any other cases of this in gnulib?
> 
> (or whether, by chance, if you know off the top of your head if any
> other gnulib consumers definitely use copy_file_range?)

Both google and cs.github.com suggest only coreutils uses copy-file-range from gnulib:
https://www.google.com/search?q=filetype%3Aconf+%22copy-file-range%22

cheers,
Pádraig

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.