bug#61386: [PATCH] cp,mv,install: Disable sparse copy on macOS

[Paul Eggert]

On 2023-02-15 06:05, George Valkov wrote:
> gcc d.c && ./a.out
> src 3  dst 4
> c 14053376  p 20344832  h 20344832  d 6291456
> total bytes copied 14053376 / 27551296

Thanks, this is due to a known incompatibility in macOS lseek that 
coreutils is supposed to work around. See 
<https://www.gnu.org/software/gnulib/manual/html_node/lseek.html>, which 
says, "On some platforms, lseek (fd, offset, SEEK_DATA) returns a value 
greater than offset even when offset addresses data: macOS 12".

I guess that somehow, the way you're building coreutils defeats the 
workaround. If so, we'll need to change how coreutils is built in your 
environment, or fix coreutils 'configure' so that the workaround isn't 
defeated in your environment. Although in 
<https://bugs.gnu.org/61386#128> Pádraig was dubious about this guess, 
his reasoning that the bug is likely specific to APFS rather than an API 
mismatch could be wrong, as I think HFS doesn't support SEEK_DATA at all 
or reports trivial answers, so coreutils is not likely to run into the 
problem on HFS even if the bug is an API issue.

Here are some things we can do to test this guess.

1. Please try the attached program e.c in place of your d.c program. e.c 
is like d.c, except it attempts to use the coreutils workaround. What 
symptoms do you observe? If e.c works then it's almost surely a problem 
in how coreutils is built (compiler options or whatnot), not in the 
coreutils workaround. If e.c does not work it's likely that the Gnulib 
workaround does not suffice on your macOS platform, in which case we 
need to improve the workaround by hacking further on e.c and porting the 
result back to Gnulib. (There are other possibilities.)

2. Please verify that coreutils cp is using the Gnulib workaround. In 
the src directory, the shell command "nm -o *.o | grep lseek" should 
output only lines containing "rpl_lseek"; there shouldn't be any lines 
saying just "lseek". Also, please run the command "objdump -d 
lib/libcoreutils_a-lseek.o" and verify that the replacement lseek is 
actually doing something nontrivial (you should get maybe three dozen 
lines of assembly language; if it's much less then this is the problem).

3. Please confirm that _DARWIN_C_SOURCE is defined to 1 in lib/config.h.

4. What is the output of the following commands, in the coreutils build 
directory?

rm lib/libcoreutils_a-lseek.o
make V=1 lib/libcoreutils_a-lseek.o
gcc -E -Ilib lib/lseek.c

e.c
Description: Text Data