SashegDev
874b6f20c2
Основа — Horizon (MIT). История апстрима не переносится: этот репозиторий ведёт свою.
45 lines
3.0 KiB
Markdown
45 lines
3.0 KiB
Markdown
# Resource preparation and filesystem work
|
||
|
||
The reported preparation timings put sounds at 20–29 seconds with little CPU use, versus
|
||
0.9–1.4 seconds for fresh client asset extraction. Prefer fewer file opens, reads and writes
|
||
over parallelizing decompression.
|
||
|
||
Preparation now shares one parsed asset index between panorama, font, pack and language imports.
|
||
Its destination verification results live only for that preparation. A subsequent invocation
|
||
checks bytes again, so it can repair corrupt resources. Existing valid destination files do not
|
||
require the original asset objects to remain installed. A saved asset index also lets preparation
|
||
preserve full imports when only cached Minecraft JARs remain.
|
||
|
||
New imports are staged beside their destination. On Linux, FICLONE is attempted first; other
|
||
filesystems fall back to copying while hashing. Cloned copies are hashed before publication.
|
||
macOS attempts clonefile with the same checked streaming fallback. A whole asset group is staged and
|
||
verified before any replacement is published; corrupt late panorama faces leave placeholders
|
||
alone. Temporary files are cleaned up on errors. This is not a transaction for rename failures
|
||
or process termination during publication: a later run repairs incomplete groups.
|
||
|
||
Unchanged JAR resources are checked by the ZIP member's size and CRC, avoiding repeated
|
||
decompression. Valid indexed replacements take precedence over JAR placeholders. Reusing checked
|
||
Minecraft imports also passes the verified artifact/library results directly to the exporters.
|
||
|
||
## An immutable store across releases
|
||
|
||
The official launcher's SHA-1 object store already provides an immutable source for indexed
|
||
assets. Independent filesystem clones let installed Horizon releases share physical blocks
|
||
where supported, without sharing writable inodes. Ordinary copies remain the fallback.
|
||
|
||
A separate Horizon store could additionally share complete preparations on filesystems without
|
||
cloning. Its key would need the pinned client/server hashes, the preparer's output version (or
|
||
the legacy source/exporter fingerprint), and the actual asset-index digest: Mojang republishes
|
||
translations without changing the Minecraft release. Two preparations with different optional
|
||
asset availability must not claim the same complete snapshot.
|
||
|
||
Before adopting that store, separate immutable runtime resources from mutable exporter scratch,
|
||
classes and logs. Publish snapshots through a temporary directory and atomic rename, give each
|
||
release an explicit reference, and define locking, corruption repair, migration and garbage
|
||
collection. Exporters must never receive a shared writable directory or hard-linked files.
|
||
The existing launcher compatibility check should choose reuse; the store should only supply its
|
||
bytes. Keep this separate from the open work on output-version compatibility (#1946/#1947).
|
||
|
||
For now, retain independent release directories and clone their resource files. This reduces
|
||
copying where the filesystem supports it without introducing a second ownership/cleanup scheme.
|