nick-boss-tech opened a new pull request, #4969: URL: https://github.com/apache/solr/pull/4969
`ShardBackupMetadata.store` overwrote the previous metadata file in place, so a crash or failure mid-write could destroy the only good copy. This stages the new metadata in a sibling temp file and publishes it with a requested atomic move (`BackupRepository.writeAtomically`, overridden in `LocalFileSystemRepository`): - the move requests `ATOMIC_MOVE` only — it no longer falls back to a non-atomic move, so an unsupported filesystem fails closed instead of silently losing atomicity; - after any staging/publication failure the temp file is cleaned up (cleanup failures are suppressed onto the original exception), leaving the previous metadata byte-for-byte intact; - Javadocs state the honest limits: Java NIO leaves replacement of an existing target provider-specific, so this does not promise portable atomic replacement, and the interface default (via `createOutput`) offers no generic atomicity guarantee. Tests: new `ShardBackupMetadataTest` (5 cases) — overwrite reads back, no delete of previous metadata on overwrite, failed overwrite keeps previous bytes, unsupported atomic move preserves existing metadata and cleans the temp file, and the interface default routes through `createOutput`. Changelog: `changelog/unreleased/SOLR-18249.yml` (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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
