Tracking Issue for fs::rename_noreplace

Feature gate: #![feature(rename_noreplace)]

This is a tracking issue for std::fs::rename_noreplace.
It works similarly to std::fs::rename except that an existing destination is never overwritten, so the call fails with ErrorKind::AlreadyExists.

Should use appropriate OS primitives for platforms that have them, and use link/unlink approach as fallback on platforms that don't support it.
Platforms that have neither a rename-without-replace syscall nor hardlinks will return ErrorKind::Unsupported, unless alternative approach exists on those platforms.

Docs must be clear that this prevents TOCTOU races, but makes no atomicity or crash-safety guarantee.

Public API

// std::fs

pub fn rename_noreplace<P: AsRef<Path>, Q: AsRef<Path>>(from: P, to: Q) -> io::Result<()>

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• ACP: rust-lang/libs-team#131
• Implementation #162027:
  • Linux/Android (renameat2)
  • Apple (renamex_np)
  • Windows (MoveFileExW)
  • link + unlink fallback
  • Other platforms: ErrorKind::Unsupported
• Final comment period (FCP)^1
• Stabilization PR

Unresolved Questions

• Directories on the fallback path: linkat will fail with EPERM, so they can't be moved there at all. The ACP suggests plain rename, so destination "must either not exist or must be an empty directory", so an empty destination directory would still be removed, or am I missing anything? Is that acceptable, or should directories error in such case?

Start with std::fs::rename_noreplace and implementation PR #162027, then review the platform checklist and the unresolved question about directories on the link/unlink fallback. Done requires the listed platform behavior, appropriate Unsupported handling, clear race-safety documentation, and eventual stabilization work.