Fix relative symlink handling in write_atomic

[cuishuang]

What does this PR try to resolve?

Fixes #17361.

cargo_util::paths::write_atomic follows symlinks before performing an atomic write. However, fs::read_link returns a relative target exactly as stored in the symlink.

The returned target was previously used directly, causing subsequent filesystem operations to interpret it relative to Cargo's process working directory. This could make the write fail or overwrite an unrelated file.

This change resolves the target against the symlink's parent directory:

resolved_path = path.parent().unwrap().join(target);

Path::join preserves absolute targets, so the existing behavior for absolute symlinks is unchanged.

How to test and review this PR?

A new unit test creates a symlink with a relative target in a directory different from the process working directory. The test verifies that:

• the actual target receives the updated contents;
• the symlink remains a symlink;
• the stored relative target remains unchanged.

I ran:

cargo +1.97.1 test -p cargo-util
cargo fmt --all -- --check

All 12 unit tests and the cargo-util doc-test passed.

[rustbot]

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @epage, @weihanglo
• @epage, @weihanglo expanded to epage, weihanglo
• Random selection from epage, weihanglo

[cuishuang]

@weihanglo Would you mind taking a look at this write_atomic symlink fix when you have a chance?

read_link() returns relative targets as stored, but write_atomic was resolving them relative to Cargo's process working directory instead of the symlink's parent. The fix resolves the target against the parent while preserving absolute-target behavior, with a focused regression test.

Thanks!

[weihanglo]

Thanks!

BTW, I found that if you have a chained of symlinks this will still fail, though this is good enough as an incremental improvment!

View changes since this review

[cuishuang]

Thanks!

BTW, I found that if you have a chained of symlinks this will still fail, though this is good enough as an incremental improvment!

View changes since this review

Thanks for pointing this out. I opened a follow-up issue for chained symlink resolution: #17443

I also have a preliminary implementation there. There are still a few design details to discuss, especially symlink loops and dangling targets. #17444

When you have time, feedback or a review would be very helpful. 😄