hard links to symlink in ~/.cargo/bin installed by rustup-init in macOS Big Sur break SuperDuper! backup

rustup-init installed by Homebrew on macOS Big Sur 11.6, when run creates a number of files in ~/.cargo/bin which are hard links to a symlink. This breaks backing up using SuperDuper! with its Smart Update option, which does not support files that are hard links to symlinks. Also, Posix specification of link says "if path1 names a symbolic link, it is implementation-defined whether link() follows the symbolic link, or creates a new link to the symbolic link itself." so the action is not well defined.

Steps

1. On macOS Big Sur, with homebrew installed, use brew install rustup-init
2. Run the command rustup-init, accepting the default installation options
3. Run the command ls -il ~/.cargo/bin/

Expected result: The 12 files in ~/.cargo/bin should be symlinks all pointing to /usr/local/bin/rustup-init with the first column (inode) all being different, and the third column (reference count of the inode) all being 1.

Actual result: The 12 files all have the same inode number and all show it having a reference count of 12.

Also, trying to make a backup of the disk using the Smart Update option of SuperDuper! 3.5-beta3 (the beta is required for compatibility with Big Sur, but the lack of support for hard links to symlinks is not a beta thing) results in an error when it tries to copy one of the link files in ~/.cargo/bin.

Possible Solution(s)
Whatever method rustup-init uses to create the links in ~/.cargo/bin to /usr/local/bin/rustup-init, it should create individual symlinks instead of what it is now doing that creates hard links to the same symlink inode.

Deleting the links and recreating them myself using ln -s commands worked around my problem with SuperDuper!.

Notes

Output of ls -il ~/.cargo/bin/ showing same inode 43077450 and reference count 12

total 0
43077450 lrwxr-xr-x  12 sidney  staff  26  3 Oct 11:38 cargo -> /usr/local/bin/rustup-init
43077450 lrwxr-xr-x  12 sidney  staff  26  3 Oct 11:38 cargo-clippy -> /usr/local/bin/rustup-init
43077450 lrwxr-xr-x  12 sidney  staff  26  3 Oct 11:38 cargo-fmt -> /usr/local/bin/rustup-init
43077450 lrwxr-xr-x  12 sidney  staff  26  3 Oct 11:38 cargo-miri -> /usr/local/bin/rustup-init
43077450 lrwxr-xr-x  12 sidney  staff  26  3 Oct 11:38 clippy-driver -> /usr/local/bin/rustup-init
43077450 lrwxr-xr-x  12 sidney  staff  26  3 Oct 11:38 rls -> /usr/local/bin/rustup-init
43077450 lrwxr-xr-x  12 sidney  staff  26  3 Oct 11:38 rust-gdb -> /usr/local/bin/rustup-init
43077450 lrwxr-xr-x  12 sidney  staff  26  3 Oct 11:38 rust-lldb -> /usr/local/bin/rustup-init
43077450 lrwxr-xr-x  12 sidney  staff  26  3 Oct 11:38 rustc -> /usr/local/bin/rustup-init
43077450 lrwxr-xr-x  12 sidney  staff  26  3 Oct 11:38 rustdoc -> /usr/local/bin/rustup-init
43077450 lrwxr-xr-x  12 sidney  staff  26  3 Oct 11:38 rustfmt -> /usr/local/bin/rustup-init
43077450 lrwxr-xr-x  12 sidney  staff  26  3 Oct 11:38 rustup -> /usr/local/bin/rustup-init

Output of rustup --version:

rustup 1.24.3 (2021-05-31)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.55.0 (c8dfcfe04 2021-09-06)`

Output of rustup show:

Default host: x86_64-apple-darwin
rustup home:  /Users/sidney/.rustup

stable-x86_64-apple-darwin (default)
rustc 1.55.0 (c8dfcfe04 2021-09-06)

Start by reproducing the rustup-init installation on macOS and inspect ~/.cargo/bin/ with ls -il. Trace the entry point that creates the links and verify that each installed command is an independent symlink rather than a hard link to one symlink inode; confirm the result using the same listing and backup scenario described in the issue.