What
State the rules for --blob-store local:<dir>: which URLs can collide on one file, what happens to files the pod did not write, and whether a directory may be shared with anything else.
Why
docs/architecture.md and the README both sell the local blob store as readable with ordinary tools, because the blob key is the resource's own path. That is a real property and it is the most immediately appealing thing about the storage model. It is also unbounded as written.
Blobs go through object_store's LocalFileSystem, which applies its own path
normalization and percent-encoding, so "mirrors the URL tree" is approximate, and the
approximation is where two distinct URLs land on one file. Candidates: case-insensitive and
case-preserving filesystems, macOS NFD normalization, %2F, component and total path length
limits, and characters legal in a URL and illegal on the filesystem.
Separately, files already in the directory were never written through LDP, so they have no
containment triple, no ETag, no ACL and no presence marker. Either the pod surfaces them, in
which case there are resources that bypassed provisioning, or it does not, in which case
ls and GET disagree, and the pod is being recommended for a directory that is also
something else.
How
- Enumerate the collision cases and decide each: refuse the write, escape further, or accept and document.
- Decide the foreign-file question. "Give the pod a directory of its own" is a legitimate answer and is what the README now says; it should be the documented contract rather than advice.
- Symlinks and
..-shaped components need a stated rule even if the answer is that object_store already forecloses them.
What
State the rules for
--blob-store local:<dir>: which URLs can collide on one file, what happens to files the pod did not write, and whether a directory may be shared with anything else.Why
docs/architecture.mdand the README both sell the local blob store as readable with ordinary tools, because the blob key is the resource's own path. That is a real property and it is the most immediately appealing thing about the storage model. It is also unbounded as written.Blobs go through
object_store'sLocalFileSystem, which applies its own pathnormalization and percent-encoding, so "mirrors the URL tree" is approximate, and the
approximation is where two distinct URLs land on one file. Candidates: case-insensitive and
case-preserving filesystems, macOS NFD normalization,
%2F, component and total path lengthlimits, and characters legal in a URL and illegal on the filesystem.
Separately, files already in the directory were never written through LDP, so they have no
containment triple, no ETag, no ACL and no presence marker. Either the pod surfaces them, in
which case there are resources that bypassed provisioning, or it does not, in which case
lsandGETdisagree, and the pod is being recommended for a directory that is alsosomething else.
How
..-shaped components need a stated rule even if the answer is thatobject_storealready forecloses them.