Enhance scratchbox storage metadata management
CI / Go Tests (push) Successful in 14s
CI / Build (push) Successful in 8s
Format / gofmt (push) Failing after 4s
Release Artifacts / Validate release tag (push) Successful in 2s
Release Artifacts / Build and release executables (push) Successful in 14s
Release Artifacts / Build and release Docker image (push) Successful in 24s

- Updated `README.md` to clarify the distinction between public scratch IDs and internal blob IDs.
- Modified `filesystem.go` to introduce a new `BlobID` field in the `Metadata` struct, ensuring the separation of public and internal identifiers.
- Implemented functions to generate and reserve unique public IDs for scratch entries, improving metadata integrity.
- Adjusted tests in `filesystem_test.go` to validate the new ID structure and ensure public IDs do not match blob hashes.
This commit is contained in:
2026-06-01 05:50:37 -05:00
parent 4579443d09
commit a3162a3e5f
3 changed files with 62 additions and 19 deletions
+1 -1
View File
@@ -294,4 +294,4 @@ Scratchbox storage is designed for a single process instance per `storage.data_d
- Do not run multiple scratchbox processes against the same data directory.
- Metadata/index writes are process-local and are not coordinated with cross-process locking.
- Scratch payload files and metadata index are encrypted at rest.
- Scratch IDs are derived from the SHA-256 of the stored blob (encrypted+gzip payload on disk).
- Public scratch IDs are short random aliases; stored blobs still use SHA-256-derived internal blob IDs on disk.