[NovumOrbis]

Summary

Preserve the identity of a successfully uploaded Quark/UC object across a short post-upload stale-listing window.

Quark may acknowledge an upload successfully while its directory listing still temporarily omits the newly created object. An immediate follow-up operation such as WebDAV DELETE can therefore fail during path resolution even though the upload itself succeeded.

Problem

Observed sequence:

1. WebDAV PUT succeeds with 201 Created.
2. Shortly afterwards, the same path is looked up again.
3. Quark's directory listing does not yet contain the newly uploaded object.
4. AList reports ObjectNotFound, so the follow-up DELETE cannot reach
   driver.Remove.

This is a read-after-write visibility issue rather than an upload failure.

Changes

• Make the Quark/UC driver implement driver.PutResult.
• Return the exact PRE-allocated FID only after the upload succeeds.
• Add a bounded recent-write identity bridge in internal/op.

The bridge is keyed by:

• storage ID
• mount path
• stable parent directory ID
• child name

and expires after one minute.

Normal provider/list lookup always runs first. The recent-write identity is used only as a fallback when the normal lookup succeeds but does not contain the recently written object.

Successful Remove invalidates the relevant recent-write identity. Rename/Move invalidate the source identity, and result-returning variants seed the destination only when they provide an authoritative non-nil object.

Safety

The bridge is bound to stable parent identity rather than pathname, preventing a child from being rebound to a newly-created same-name directory after the original parent is renamed, moved, or removed.

The change does not:

• turn arbitrary missing DELETEs into success
• bypass the real provider-side Remove call
• retry or replay Quark upload PRE
• weaken the fail-closed PRE handling from fix(quark): fail closed on ambiguous upload pre responses #9660

Validation

Validated on the current main + PR merge result with:

• go test ./drivers/quark_uc
• go test -race ./drivers/quark_uc
• go vet ./drivers/quark_uc
• go test ./internal/op
• go test -race ./internal/op
• go vet ./internal/op
• go test ./server/webdav
• go test -race ./server/webdav
• go vet ./server/webdav
• targeted post-upload regression tests repeated 50 times
• targeted race tests repeated 10 times
• parent rename/move/remove + same-name recreation safety probes
• NoOverwriteUpload success and rollback probes
• gofmt
• git diff --check

No real Quark/UC provider traffic was used during validation.

Related

• fix(quark): fail closed on ambiguous upload pre responses #9660 hardens ambiguous Quark upload PRE handling.
• fix(quark): recover ambiguous delete failures #9651 addresses a separate provider-side ambiguous DELETE case.