You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Stop an export from deleting chunks it was never asked about
Somebody walked the whole path in the native window and reported two things
about the end of it. Looking into those found a third, which is the worst defect
this project has had.
An export replaced whole region files. A region file holds up to 1,024 chunks
and an export usually has a handful in any one of them, so laying the file out
from what it was given and writing it over the old one deleted the rest: chunks
this archive never observed and had no standing to touch. Nothing failed,
because a shorter file is not an error.
Their world went from 16 MB to 2.8 MB. Its point-of-interest data, which an
export does not write, still names 29 chunks in the two regions that were
replaced, and those chunks are gone. Nothing had warned them: the heuristic that
asks "have you played in this?" only speaks above 40 MB and that world was 16.
Region.Adopt now reads a region file that is already there and keeps every chunk
the export does not supply. Frames are copied through without being
decompressed, parsed or re-encoded, because this archive did not observe them and
has no business having an opinion about their contents, only about not losing
them. Where the two meet the export wins, so it can still correct what it wrote
before. A file that cannot be read stops the export rather than being replaced by
a smaller one, and it is read before anything is written, so a refusal leaves the
world alone.
Measured on the data that exposed it: writing the six chunks this archive holds
for top.earthmc.net into a copy of that world, whose region file held 380,
reported 374 kept, and the world's chunk count across all six region files was
552 before and 552 after. With adoption disabled the same test finds 2 chunks
where 14 should be. ExportReport carries Kept, the window reports it, and the
confirmation stops saying recordings are written over "where they overlap what is
there", which described chunks and was true of nothing.
The two things they actually reported are fixed too.
The window never declared DPI awareness, and neither does the library it uses, so
on any display scaled above 100% Windows drew it for 96 dots per inch and
stretched the result -- everything working, every letter soft. It now asks for
per-monitor awareness through three generations of the same call, and scales its
opening size to match, because a window asked for in 96-dpi pixels comes out
physically small once the process is aware.
And the path ended in one green line where the whole screen had been. The last
screen now answers what actually gets asked there: what went in, what was already
in that world and survived, which files were written, where it is, and what to do
next. On the same run the install had refused after they typed a name, read five
file paths and agreed to all five, because a build from source carries no address
for the mod; that refusal now happens before the asking, since consent collected
for something that cannot happen is worse than not asking at all.
Copy file name to clipboardExpand all lines: docs/status.md
+20Lines changed: 20 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -75,6 +75,26 @@ Two smaller ones came from the same walk. 608 recordings already taken in were o
75
75
76
76
**How the application asks.** Everything consequential — writing five files into a Minecraft, removing them again, deleting recordings, writing over a world somebody has played in — was agreed to in `window.confirm`. That heads the question with `127.0.0.1:53211 says`, renders a list of file paths as one run of text, and makes consent depend on script dialogs being switched on in whatever is showing the page. It is now a sheet in the application, with each file as its own row and its full path; Escape and Cancel both answer no. Checked in the running application: the five planned files appear as five rows, cancelling wrote nothing, and a `mods` folder still does not exist on the machine it was tried on.
77
77
78
+
**The worst defect this project has had, found by somebody using the window.**
79
+
80
+
An export replaced whole region files. A region file holds up to 1,024 chunks; an export usually has a handful in any one of them; the file was laid out from what the export was given and written over what was there. Every other chunk in it was deleted — chunks this archive never observed and had no standing to touch — and nothing failed, because a shorter file is not an error.
81
+
82
+
It was found by a person walking the path in the native window. They exported into a world they had made two weeks earlier, and it went from 16 MB to 2.8 MB. The world's own point-of-interest data, which the export does not write, still names 29 chunks in the two regions it replaced; those chunks are gone. Nothing had warned them, because the size heuristic that asks "have you played in this?" only speaks above 40 MB and that world was 16.
83
+
84
+
Three things were wrong at once and all three are fixed:
85
+
86
+
-**The write was destructive.**`Region.Adopt` now reads a region file that is already there and keeps every chunk the export does not supply, copying the frames through without decompressing, parsing or re-encoding them: this archive did not observe them and has no business having an opinion about their contents, only about not losing them. Where the two meet, the export wins, so it can still correct what it wrote before. A region file that cannot be read stops the export instead of being replaced by a smaller one, and it is read before anything is written, so a refusal leaves the world alone.
87
+
-**It was measured on the data that exposed it.** Writing the 6 chunks the archive holds for `top.earthmc.net` into a copied world whose region file held 380 reported 374 kept, and the world's chunk count across all six region files was 552 before and 552 after. Before the fix the same operation left that file with 6.
88
+
-**The confirmation was reassuringly wrong.** It said recordings are written over "where they overlap what is there", which describes chunks and was true of nothing. It now says a place you recorded that also exists there is replaced and everywhere else is left alone, which is what the code does.
89
+
90
+
`ExportReport` carries `Kept`, and the window reports it, because "did this eat my world" is the question somebody actually has and the export previously could not answer it.
91
+
92
+
**Two more things that person found, which the walkthrough before them had not.**
93
+
94
+
The window is now told to draw at the display's real resolution. It never declared DPI awareness and the library it uses does not either, so on any display scaled above 100% Windows rendered it for 96 dots per inch and stretched the result: everything worked and every letter was soft. The initial size is scaled to match, because a window asked for in 96-dpi pixels comes out physically small once the process is aware.
95
+
96
+
And the path ended without saying what had happened. It ended in one green line where the whole screen had been — no count, no folder, no files, nothing about what was already in that world. The last screen now answers the four questions that are actually asked there: what went in, what was already there and survived, where it is, and what to do next. On the same run, the install had also refused *after* the person had typed a name, read five file paths and agreed to all five, because a build from source carries no address for the mod; that refusal now happens before the asking, since consent collected for something that cannot happen is worse than not asking.
97
+
78
98
**In the native window, as far as it was watched.** All of the above was exercised through the browser, which is the same page and the same server but not the same renderer. The window was then opened on Windows against the WebView2 runtime 151.0.4129.101 and a capture of it shows the application drawing: the numbered rail, the disposition cards, and a server's existing decision shown as the selected one. Within four seconds of that window opening, the first-run notice was accepted and written to disk, so the sheet appeared in the window, its button answered, and the request reached the archive's own directory — but the click was not this project's to claim, because somebody was at the keyboard, and it is recorded here as what it is rather than as a run.
79
99
80
100
What was not done is driving that window further. Doing so means taking over the screen of whoever is using the machine, and the attempt to do it captured a window that had nothing to do with this project, which is reason enough to stop. The confirmation sheet is therefore covered in the window only by what it shares with the notice: they are one element wearing two ids, with the same class and the same code, and the contract test under `desktop/ui` fails if they stop being so. That is a smaller claim than a run and it is the one the evidence supports.
0 commit comments