[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: bug#61386: [PATCH] cp,mv,install: Disable sparse copy on macOS
Date: Wed, 15 Feb 2023 11:26:36 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1

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

Attachment: e.c
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]