Let a disc prove it is still what you burned - #104
Merged
Merged
Conversation
Asked for as being able to restore a disc back to its original bin and exe structure, matching the original hash values. The structure half already worked. A disc built here, extracted again, comes back byte for byte with its names intact, under both filesystem options, including a 112-character name. That was measured before any of this was written, because it decided what the feature had to be. What was missing was any way to prove it, which is the one thing a disc cannot tell you about itself. A third checkbox on the row that already offers Linux naming and XP readability writes checksums.sha256 at the disc root: one line per file, SHA-256, in the format sha256sum uses, so nothing from DiscWright is needed to read it. That matters for a file whose whole job is to still be useful in twenty years. The header carries a PowerShell loop that does the same job on a machine with nothing installed, and that loop was run as printed, against a file corrupted by one byte, rather than written and assumed. Lines end with a newline alone, unlike every other file this writes. sha256sum -c takes a carriage return as part of the filename and reports every line as a missing file. A test pins it, because only the real tool showed it. Off by default, like the two beside it, on the principle already written down here: what every disc carries is not a decision to make on somebody's behalf. The cost is one pass over the data, about three seconds for a CD and eight minutes for a filled Blu-ray, and it cannot be folded into the staging copy because a same-volume build hard-links its files and never reads them. It covers the menu and the icon as well as the games, so a disc verifies whole and a game restored out of it still has its own lines. Project schema goes to 11. Absent in anything older, which reads back as off, so reopening an old project and rebuilding produces the disc it produced before. Refs #98. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes item 2 of #98.
The structure half already worked
Before writing anything I measured whether a disc restores identically, because that decided what the feature needed to be:
That included a 112-character filename, longer than Joliet's limit, which survives because IMAPI writes long names into the ISO9660 tree and 7-Zip reads the UDF one. So nothing was broken. What was missing was any way to prove it, which is the one thing a disc cannot tell you about itself.
What the disc gains
A third checkbox on the row that already offers Linux naming and XP readability:
It writes
checksums.sha256at the disc root, one line per file:Nothing from DiscWright is needed to read it, which rather matters for a file whose whole job is to still be useful in twenty years.
sha256sum -cchecks it directly, and for a Windows machine with nothing installed the header prints a PowerShell loop that does the same thing.It covers the menu and the icon as well as the games, so a disc verifies whole and a game restored out of it still has its own lines to check against.
Two things only the real tools showed
CRLF silently broke the format
The first version used CRLF like every other file DiscWright writes.
sha256sum -ctakes the carriage return as part of the filename:Every line reported as a missing file. It writes LF now, and a test pins it. Reading the output would never have shown this; running the checker did.
The instructions in the header are tested, not assumed
The file prints a PowerShell loop for machines without coreutils. That loop was run exactly as printed, including against a file corrupted by one byte:
Shipping verification instructions that do not work would be worse than shipping none.
Cost, measured
About 204 MB/s on this machine, one pass over the data:
It cannot be folded into the staging copy to make it free: when source and output share a volume the build hard-links its files and never reads them.
Off by default, like the two beside it, on the principle already written into this file: what every disc carries is not a decision to make on somebody's behalf.
Tests
Get-FileHashcomputes, rather than agreeing with the code that wrote itsha256sum -caccepts the file, checked with the real tooltests\Invoke-Tests.ps1The window suite matters here because the row gained a control and the icon preview moved to make room; the layout test that checks for overlapping controls passes.
Project schema goes to 11. Absent in anything older, which reads back as off, so reopening an old project and rebuilding produces the disc it produced before.
🤖 Generated with Claude Code