cargo add overwrites a symlink Cargo.toml

[Axlefublr]

Problem

I'll start with a codeblock as imo it's the most straightforward explanation:

$ ls -l
drwxr-xr-x src
lrwxrwxrwx target -> /home/axlefublr/.cache/wks/hello-world.rs/target
lrwxrwxrwx Cargo.lock -> /home/axlefublr/.cache/wks/hello-world.rs/Cargo.lock
lrwxrwxrwx Cargo.toml -> /home/axlefublr/.cache/wks/hello-world.rs/Cargo.toml

$ cargo --version
cargo 1.87.0-nightly (1d1d646c0 2025-02-21)

$ rustup run stable cargo --version
cargo 1.85.0 (d73d2caf9 2024-12-31)

$ rustup run stable cargo add clap
    Updating crates.io index
      Adding clap v4.5.31 to dependencies
			// --SNIP--

$ ls -l
drwxr-xr-x src
lrwxrwxrwx target -> /home/axlefublr/.cache/wks/hello-world.rs/target
lrwxrwxrwx Cargo.lock -> /home/axlefublr/.cache/wks/hello-world.rs/Cargo.lock
.rw-r--r-- Cargo.toml

$ rm -fr Cargo.toml

$ ln -sf ~/.cache/wks/hello-world.rs/Cargo.toml ./Cargo.toml

$ cargo add clap
    Updating crates.io index
      Adding clap v4.5.31 to dependencies
			// --SNIP--

$ ls -l
drwxr-xr-x src
lrwxrwxrwx target -> /home/axlefublr/.cache/wks/hello-world.rs/target
lrwxrwxrwx Cargo.lock -> /home/axlefublr/.cache/wks/hello-world.rs/Cargo.lock
.rw-r--r-- Cargo.toml

I have Cargo.toml symlinked to the real Cargo.toml somewhere else. When using cargo add, I expect the symlink to not be broken. However, cargo add overrides the symlink into being a normal file, breaking the symlink tie to that other Cargo.toml.
I don't think that's intentional.

Steps

mkdir -p test/src
cd test
touch src/main.rs
ln -sf ~/.cache/wks/hello-world.rs/Cargo.toml ./Cargo.toml # path to some other Cargo.toml goes here, instead of the first path
cargo add clap # doesn't matter which dependency you add

viola. stat the Cargo.toml to see that it's now a regular file, rather than a symlink.
the target Cargo.toml stays untouched, btw

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.85.0 (d73d2caf9 2024-12-31)
release: 1.85.0
commit-hash: d73d2caf9e41a39daf2a8d6ce60ec80bf354d2a7
commit-date: 2024-12-31
host: x86_64-unknown-linux-gnu
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.9.0-DEV (sys:0.4.74+curl-8.9.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: EndeavourOS Rolling Release (rolling) [64-bit]

[Axlefublr]

for those curious to know why I'm using a Cargo.toml symlink in the first place, read my blog post on that (I didn't make this issue for advertising; I'm just answering a very likely question in advance)

[epage]

With #11386 we switched to atomic writes in #12744. We had permission issues with that in #13896 which we then fixed in #13898.

Maybe we should follow the symlinks and do the atomic writes in that location.

[epage]

btw are you aware of native support for cargo script? I posted an update today on it at https://blog.rust-lang.org/inside-rust/2025/02/27/this-development-cycle-in-cargo-1.86.html#cargo-script

I would be interested in performance feedback. While we likely won't be doing any cargo-script-specific layers of caching, I'm hopefully we can get cargo-script itself to be "fast enough".

[Axlefublr]

@epage I'm glad that cargo-script is being worked on on the core side, but it's probably not going to plug all of my holes as well as my current system does

rust-analyzer support I heard is coming, which is great news!
but many of the rust scripts I write are more so unixy programs than traditional scripts. things like "print a range of lines of a file", "append a line onto a file correctly even if it has a missing final newline", "print the first n lines in a file and remove them from that file" — all of those things are practically missing gnu programs, and core functionality that becomes a part of my system I want to be indesputably fast
if I have that need for some of my scripts, I might as well use my system for all of my scripts, rather than jumping in and out of cargo-script

I avoid writing fish scripts and instead write fish functions specifically because of the startup cost; I can't see cargo-script not having that cost, unfortunately

[Axlefublr]

better way to phrase things: I have a rust binary generating system, not a rust scripting system. so I think I'm just not the audience for cargo-script, lol