Hi Kevin, I have tested it on macOS 26.4. Bug no longer reproduces with my test samples. Thank you for the fix! Regarding "fclonefileat" API my expectations are actually met in macOS 26.4 now - I do expect that Kernel is capable of rejecting invalid calls of "clonefile" API and does fail the operation. It is tricky to predict the future as there might be new regular file type that might not be clonable/will become clonable so I always delegate the file clonability decision to Kernel. My userland code is to handle the errors gracefully, although fallback in case of rsrc needs to be reconsidered... It is on my side though, I do not see any further enhancements needed in Kernel currently. For backwards compatibility, I will include explicit careful checks for resource forks and paths with "..namedfork/" as you have suggested. I appreciate your help!

Hi Kevin, I appreciate your suggestions. I was working on implementing them in our code and found a peculiar test in our coverage that boils down to the following piece of code: #include <string> #include <sys/fcntl.h> #include <sys/mman.h> #include <unistd.h> int main() { std::string path = "/private/tmp/test"; close(creat(path.c_str(), 0777)); std::string rsrcPath = path + "/..namedfork/rsrc"; int fd = open(rsrcPath.c_str(), O_CREAT | O_WRONLY, 0666); printf("%d\n", fd); write(fd, "rsrc", 4); { int fd1 = open(rsrcPath.c_str(), O_RDWR, 0666); void* ptr = mmap(nullptr, 10, PROT_READ | PROT_WRITE, MAP_SHARED, fd1, 0); printf("%s -> %p|%d\n", rsrcPath.c_str(), ptr, fd1); munmap(ptr, 10); close(fd1); } unlink(path.c_str()); close(fd); return 0; } Running this tool will immediately cause kernel panic: panic(cpu 1 caller 0xfffffe00254a7590): "Trying to update a namedstream inode 118a7 on volume Data\n" @jobj.c:4416 Debugger message: panic Memory ID: 0x0 OS release type: User OS version: 25E253 Kernel version: Darwin Kernel Version 25.4.0: Thu Mar 19 19:29:33 PDT 2026; root:xnu-12377.101.15~1/RELEASE_ARM64_VMAPPLE I ran it on latest ARM macOS 26.4.1 and Intel macOS 15.7.5. I assume mmap route hits some kind of edge case that might be worth investigating on the kernel side.