Composer package installation: duplicate writes during retry cycles

Composer implements a retry mechanism for failed package downloads, governed by the COMPOSER_MAX_RETRIES environment variable and the --prefer-dist or --prefer-source flags. This process is designed to ensure package availability despite transient network instability.

A potential conflict exists when a download is interrupted after a partial write to the filesystem. If the retry logic initiates a new download attempt without first verifying the integrity or clearing the partially written temporary file, there is a risk of non-idempotent write operations. This may result in duplicate entries or corrupted files within the vendor directory upon completion.

For Composer 2.x environments, it is unclear how the internal file handling prevents these duplicate writes during automatic retries. Specifically:

• Does the retry mechanism perform an atomic rename or a checksum validation of existing partial files before restarting the download?
• What is the documented behavior for cleaning up orphaned partial writes when a retry is triggered?