Dataloss copying file using copy-file on RHEL 8.

[David Koppelman <koppel@ece.lsu.edu>]

I'm experiencing incompletely copied files when using (copy-file). I'm
not sure if this is an Emacs problem, but because it's serious I
thought I'd report it here in case it is.

On a Red Hat Enterprise Linux 8 build of recent git pulls of Emacs I
experienced file corruption when copying a file into an existing file.
I discovered it using C in dired, but the problem is reliably
reproduced calling copy-file with the KEEP-TIME argument t: (copy-file
"porig.svg" "pcopy.svg" t t) (I recently upgraded from rhel 7 to rhel
8 so the problem may have nothing to do with a recent change to
Emacs.)

I get the problem when copying a 36368-byte file to an existing file
of the same size, both files are on the same NFS-mounted filesystem.
The problem does not occur on XFS. The contents of the destination
file is correct for the first 32768 bytes, then the remainder of the
file--which is the right size--is set to 0.

Running under gdb reveals that the file is copied using
copy_file_range (in src/fileio.c). I can work around the problem by
forcing Emacs to avoid the loop using copy_file_range, in which case
it uses fallback code and everything is fine. (Except I don't get the
efficient kernel-space-to-kernel-space transfer that copy_file_range
uses.)

I do not experience the problem on the version of Emacs packaged with
rhel 8, "GNU Emacs 26.1 (build 1, x86_64-redhat-linux-gnu, GTK+
Version 3.22.30) of 2018-09-10".

When I have time I'll try to reproduce the problem with a quick C++
routine using copy_file_range. If successful, I'll file a bug with Red
Hat. Even if this is a rhel 8 problem, Emacs ought to avoid
copy_file_range when it does or might occur.

David Koppelman