On 09/02/2023 09:20, George Valkov wrote:
Due to a bug in macOS, sparse copies are corrupted on virtual disks
formatted with APFS. HFS is not affected. Affected are coreutils
install, and gcp when compiled with SEEK_HOLE, as well as macOS Finder.
While reading the entire file returns valid data, scanning for
allocated segments may return holes where valid data is present.
In this case a sparse copy does not contain these segments and returns
zeroes instead. Once the virtual disk is dismounted and then
mounted again, a sparse copy produces correct results.
This breaks OpenWRT build on macOS. Details:
https://github.com/openwrt/openwrt/pull/11960
https://github.com/openwrt/openwrt/pull/11960#issuecomment-1423185579
Signed-off-by: Georgi Valkov <gval...@gmail.com>
---
src/copy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/copy.c b/src/copy.c
index e16fedb28..4f56138a6 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -1065,7 +1065,7 @@ infer_scantype (int fd, struct stat const *sb,
return PLAIN_SCANTYPE;
}
-#ifdef SEEK_HOLE
+#if defined(SEEK_HOLE) && !defined(__APPLE__)
scan_inference->ext_start = lseek (fd, 0, SEEK_DATA);
if (0 <= scan_inference->ext_start || errno == ENXIO)
return LSEEK_SCANTYPE;
Thanks for the detailed report.
The patch might very well be appropriate.
We avoided copy_file_range() for a long time on Linux for example
until it became usable.
Thanks for confirming the latest git is also impacted.
I see you're on macOS 12.
macOS 13 supports fclonefileat() which may
avoid the issue, or also be impacted?
I wonder might an fdatasync(fd) avoid your issue,
which we might do if defined(__APPLE__)?
cheers,
Pádraig