Pádraig Brady <[email protected]> writes:

> 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 /tmp
>>      removed '/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.

True, I guess it applies for 'mv'. I wasn't thinking much about it since
we try to avoid copying where possible. But sometimes it isn't.

> 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

I like the --reflink[=WHEN] interface better than "--link linkflags".

But I am okay with using the ones that FreeBSD does support:

       -l linkflags
               Instead  of  copying  the  file make a link to the source.  The
               type of the link  is  determined  by  the  linkflags  argument.
               Valid  linkflags  are:  a (absolute), r (relative), h (hard), s
               (symbolic), m (mixed).  Absolute and relative have effect  only
               for  symbolic  links.   Mixed links are hard links for files on
               the same filesystem, symbolic otherwise.

Collin

Reply via email to