On 05/02/2026 05:02, Collin Funk wrote:
Hi,Is there a reason that 'install --reflink' does not exist? I was curious myself, and saw someone asked the same thing a few years ago [1]. As far as I can tell they didn't get a response, but the lists.gnu.org interface isn't great at tracking things across months so I could have missed it. I can't immediately think of why it shouldn't be supported. Both cp and install have --debug, though I suppose that is more useful for --reflink=auto and copying items which may go to a different file system. Anyways, I attached a example patch since it isn't that difficult to share the code. Here is the output with --debug: $ ./src/ginstall --debug a ../ 'a' -> '../a' copy offload: unknown, reflink: yes, sparse detection: unknown$ ./src/ginstall --debug a /tmp'a' -> '/tmp/a' copy offload: unsupported, reflink: unsupported, sparse detection: no$ ./src/ginstall --debug --reflink=never a ../removed '../a' 'a' -> '../a' copy offload: avoided, reflink: no, sparse detection: no$ ./src/ginstall --debug --reflink=always a /tmpremoved '/tmp/a' 'a' -> '/tmp/a' ginstall: failed to clone '/tmp/a' from 'a': Invalid cross-device link copy offload: unknown, reflink: unsupported, sparse detection: unknown Missing documentation and tests, of course. Collin [1] https://lists.gnu.org/archive/html/coreutils/2019-11/msg00002.html
There is less of a use case for reflink control with install(1). The same arguments apply to mv(1) really. Also what about --link and --symbolic-link. This was discussed recently actually at: https://github.com/coreutils/coreutils/issues/115 The summary there was to possibly reuse the FreeBSD interface to support, -l,--link=TYPE where TYPE is mixed, hard, absolute, relative, symbolic, reflink, none cheers, Padraig
