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

[George Valkov]

> On 2023-02-15, at 9:48 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
> 
> On 2023-02-15 07:26, George Valkov wrote:
>> I tested your patch: both overwrite existing and clone to new produce a 
>> working copy. Here are the test results:
>> https://httpstorm.com/share/.openwrt/test/2023-02-06_coreutils-9.1/test-04-cf80f988eeb97cc3f8c65ae58e735d36f865277b-clone.txt
> 
> I see some test failures there, involving cp. Do you get the same set of test 
> failures without the patch?

Yes. Note that Pádraig disabled two tests which fail after the patch:
tests/cp/thru-dangling.sh, tests/seek-data-capable (the actual test that failed 
was related to sparse, I think sparse-extents.sh)

https://httpstorm.com/share/.openwrt/test/2023-02-06_coreutils-9.1/test-01-cf80f988eeb97cc3f8c65ae58e735d36f865277b-ori.txt
https://httpstorm.com/share/.openwrt/test/2023-02-06_coreutils-9.1/test-04-cf80f988eeb97cc3f8c65ae58e735d36f865277b-clone.txt


>> In the case when a dangling symlink is involved and depending on the 
>> arguments passed to cp, would it be possible to use CLONE_NOFOLLOW with 
>> fclonefileat or fall-back to a normal copy? Does dangling refer to source or 
>> destination?
> 
> Dangling refers to the destination. The latest proposed patch does use 
> CLONE_NOFOLLOW, which means fclonefileat should not follow symlinks to the 
> destination. (This behavior is not documented, unfortunately, but it's the 
> only behavior that makes sense.)

Ok, thank you for clarifying!
Good luck!


Georgi Valkov
httpstorm.com
nano RTOS