#414: s3 driver — canonical-equivalence tolerant key addressing #417
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "s3-unicode"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #414.
Root cause:
CleanPathcanonicalises every path to NFC (#183), including paths from the driver's own List — legacy NFD keys (macOS decomposed uploads pre-#183) listed fine but 404ed on Open/Delete, and S3's idempotent DELETE turned removal into a silent no-op. That is the exact life story of the/home/Mülltrennung.docxghost.Fix (canonical writes + equivalence-tolerant addressing):
storage.AltUnicodeForm(ASCII short-circuit, zero cost on the hot path) + driver-levelresolve: when the canonical key is absent but its alternate form exists (exact object, dir marker, or prefix children), operations address the stored bytes — Stat/List/Open/Delete/Copy-source. Stat and List report backend-true paths, keeping roundtrips byte-faithful — the APFS school of form-insensitive lookup.storageso the POSIX driver can adopt the same fallback if the exposure ever surfaces there.Tests: in-process fake S3 backend (byte-opaque, like the real thing); all unicode built from code points, never literals. Covers: NFD file roundtrip via listing path and via canonical path, delete-really-deletes (no 204 illusion), in-place twin overwrite, canonical new writes even from NFD input, NFD directory prefix resolution.