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
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:
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user