Quota enforcement at the storage write chokepoint (v0.3 #14) #34
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/quota-enforcement"
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 the last v0.3 functional gap: quota enforcement (reporting shipped in v0.2.1).
Design: a
internal/storage/quotadecorator around the single storageWritechokepoint (same pattern as the encrypt decorator), so REST, WebDAV PUT, and TUS finalize are all covered by one implementation.storage.Usager(POSIX statfs); silently skipped on backends without it (S3).storage.ErrQuotaExceeded→ 507 Insufficient Storage on WebDAV, JSON error on REST, 507 on TUS finalize.storage.quota { enabled, maxFileBytes, maxTotalBytes, reserveBytes }+CAIRN_QUOTA_*env overrides. Wired as the outermost storage decorator inmain.go(counts plaintext size, sees forwarded Usage).Bonus fix: the encrypt decorator now forwards
Usage, so quota reporting (and this enforcement's capacity guard) work on POSIX+encryption deployments — previously the decorator hid theUsagercapability and/quotafell to 501. Also corrects the stale "age is NOT post-quantum" comment inencrypt.go.Per-user quotas are deferred to v0.4 (they need the per-user home-dir/accounting model, #16). Unit tests cover max-file, total/reserve guards, usage forwarding, non-Usager skip, and passthrough.