GNU bug report logs -
#63850
cp fails for files > 2 GB if copy offload is unsupported
Previous Next
Reported by: Sam James <sam <at> gentoo.org>
Date: Fri, 2 Jun 2023 15:50:02 UTC
Severity: normal
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
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 63850 <at> debbugs.gnu.org.
--
63850: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63850
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
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.
[Message part 3 (message/rfc822, inline)]
[Message part 4 (text/plain, inline)]
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!
[signature.asc (application/pgp-signature, inline)]
This bug report was last modified 1 year and 350 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.