Comment by Joker_vD
1 day ago
> When cp was invented, 'most filesystems' did not have the first clue about copy on write.
Eh, when fork was invented, most (virtual) memory systems did not have the first clue about copy-on-write either. And honestly, it's really not that difficult to support — it's essentially hard links, just with slightly different semantics.
In theory, I agree that it shouldn't be tricky. However, in practice, it is a bit tricky since all the different implementations have different ways to perform reflinks.
Linux has FICLONE [1], which I prefer because it operates on two file descriptors, allowing you to safely modify file metadata after the fact. macOS has clonefile, clonefileat, and fclonefileat [2]. Sadly, there is no way to operate on two file descriptors. The best you get is fclonefileat, which operates on a source file descriptor. Solaris has reflink and reflinkat, which operate on two paths, the latter relative to file descriptors [3]. In that case, one needs to be careful opening the destination to make changes to the metadata.
GNU coreutils has support for reflinks on Linux and macOS. But I've been thinking about adding support for Solaris as of late [4]. Sadly, I don't use it enough to test it as much as I would like.
Hopefully, a few years down the line the interfaces converge, and it is as simple as hard linking.
[1] https://man7.org/linux/man-pages/man2/FICLONE.2const.html [2] https://www.manpagez.com/man/2/clonefile/ [3] https://docs.oracle.com/cd/E86824_01/html/E54766/reflinkat-3... [4] https://lists.gnu.org/archive/html/coreutils/2026-09/msg0012...