hfutatzhanghb commented on code in PR #7815: URL: https://github.com/apache/opendal/pull/7815#discussion_r3487873308
########## core/core/src/docs/rfcs/7815_rename_if_not_exists.md: ########## @@ -0,0 +1,199 @@ +- Proposal Name: `rename_if_not_exists` +- Start Date: 2026-06-23 +- RFC PR: [apache/opendal#7815](https://github.com/apache/opendal/pull/7815) +- Tracking Issue: [apache/opendal#0000](https://github.com/apache/opendal/issues) + +# Summary + +Add `Operator::rename_if_not_exists` and +`blocking::Operator::rename_if_not_exists`. + +The operation renames a source file only when the destination file does not +exist. If the destination file exists, it returns `AlreadyExists` and leaves +both files unchanged. The existing `rename` API keeps its overwrite semantics. + +# Motivation + +OpenDAL defines `rename` as an overwrite operation. This gives users consistent +behavior across services even when a backend's native rename does not overwrite +the destination. + +Some applications also need to publish a file only if no other writer has +already published the destination. Implementing this as `stat` followed by +`rename` is unsafe because another writer can create the destination between +the two operations. A service-specific configuration flag has a different +problem: it changes the meaning of the standard `rename` operation and makes +portable code depend on backend configuration. + +OpenDAL needs a separate operation that expresses the destination condition +directly and allows services to advertise whether they can enforce it. + +# Guide-level explanation + +Use `rename` when an existing destination should be replaced: + +```rust +op.rename("staging/file", "published/file").await?; +``` + +Use `rename_if_not_exists` when an existing destination must be preserved: + +```rust +use opendal::{ErrorKind, Operator, Result}; + +async fn publish(op: Operator) -> Result<()> { + match op + .rename_if_not_exists("staging/file", "published/file") Review Comment: have fixed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
