# Names, collisions, and replacement

A destination may already contain an item with the same name as a selected file. Review the collision information and choose the available policy deliberately. The same filename does not prove that two items contain the same bytes or represent the same revision.

## Replacing a file

File replacement uses verified transfer and removal behavior. Strive verifies the copied bytes and enforces the applicable revision conditions. If the destination or source no longer matches the conditions admitted for the operation, the operation can refuse to proceed instead of overwriting an unexpected item.

Check whether the existing destination contains work that should be preserved. A replacement is not a merge of two documents and does not preserve all provider version history or comments from the replaced item.

## Folders are different

Folder replacement is refused. The browser does not recursively replace an existing destination folder and erase its contents as a side effect of a same-name conflict. Choose a different destination, change the name, or resolve the conflict explicitly before starting again.

Creating or renaming a folder should use the available provider action and a name valid for that provider. If a rename is implemented through copy and removal, its outcome can include retained source content. Inspect the result instead of assuming every provider supports the same atomic rename behavior.

## Retry carefully

A job may have already copied some items before encountering a collision. Review the existing job and destination before issuing another request. A retry is not a promise to roll back successful prior files or replace every remaining item automatically.

When the result is ambiguous, inspect both locations and the operation receipt. Avoid repeatedly replaying an uncertain destructive action. See [jobs and recovery](/docs/storage/jobs-and-recovery) for how to distinguish a safe retry from a new transfer.