What would you like to be added?
Conditional-write support (if_match / if_none_match on write_with) is currently inconsistent across the S3-family object storage services:
- S3:
if_match is fully implemented. if_none_match with an arbitrary ETag is not implemented — this is a genuine limitation of the S3 API itself, since x-amz-if-none-match only ever accepts the literal wildcard *, which is already covered by if_not_exists().
- Azure Blob:
if_none_match is fully implemented, but if_match is missing even though Azure's Put Blob REST API supports If-Match with an arbitrary ETag.
- GCS: Neither
if_match nor if_none_match is implemented for writes. GCS's JSON API (used by OpenDAL for uploads) has no ETag-based conditional-write mechanism at all — only generation/metageneration-number query parameters (ifGenerationMatch, ifGenerationNotMatch), which is exactly what the existing if_not_exists() → ifGenerationMatch=0 code already uses.
We should close the two gaps that are actually implementable given each provider's API:
- Add
write_with_if_match support to Azure Blob (wire If-Match into azblob_put_blob_request, mirroring the existing if_none_match handling).
- Add
write_with_if_match / write_with_if_none_match support to GCS on top of ifGenerationMatch / ifGenerationNotMatch, using the object's generation number (already exposed via Metadata::version()) rather than a literal ETag, since GCS has no ETag-based conditional-write primitive.
S3 requires no change, since its remaining gap is a hard API limitation rather than a missing implementation.
Why is this needed?
This enables optimistic-concurrency writes (e.g. "only overwrite if the object hasn't changed since I last read it") consistently across more backends, closing capability gaps that currently silently no-op (write_with_if_match/write_with_if_none_match report false even where the underlying API could support them).
What would you like to be added?
Conditional-write support (
if_match/if_none_matchonwrite_with) is currently inconsistent across the S3-family object storage services:if_matchis fully implemented.if_none_matchwith an arbitrary ETag is not implemented — this is a genuine limitation of the S3 API itself, sincex-amz-if-none-matchonly ever accepts the literal wildcard*, which is already covered byif_not_exists().if_none_matchis fully implemented, butif_matchis missing even though Azure's Put Blob REST API supportsIf-Matchwith an arbitrary ETag.if_matchnorif_none_matchis implemented for writes. GCS's JSON API (used by OpenDAL for uploads) has no ETag-based conditional-write mechanism at all — only generation/metageneration-number query parameters (ifGenerationMatch,ifGenerationNotMatch), which is exactly what the existingif_not_exists()→ifGenerationMatch=0code already uses.We should close the two gaps that are actually implementable given each provider's API:
write_with_if_matchsupport to Azure Blob (wireIf-Matchintoazblob_put_blob_request, mirroring the existingif_none_matchhandling).write_with_if_match/write_with_if_none_matchsupport to GCS on top ofifGenerationMatch/ifGenerationNotMatch, using the object's generation number (already exposed viaMetadata::version()) rather than a literal ETag, since GCS has no ETag-based conditional-write primitive.S3 requires no change, since its remaining gap is a hard API limitation rather than a missing implementation.
Why is this needed?
This enables optimistic-concurrency writes (e.g. "only overwrite if the object hasn't changed since I last read it") consistently across more backends, closing capability gaps that currently silently no-op (
write_with_if_match/write_with_if_none_matchreportfalseeven where the underlying API could support them).