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
An export wrote its temporary to a fixed name -- the target with ".tmp" on the
end. That is only safe while one writer exists at a time, and there is no such
guarantee: the window's export lock is in-process, so a command line export and
the window together, or two exports into one world, opened the same file with
O_TRUNC, interleaved their bytes, and both renamed the mixture over a region
file in somebody's save. The name is unique now and the contents are forced to
disk before the rename, because a region file that is a rename away from
complete but whose bytes never landed is a corrupt chunk rather than a missing
one. Checked on a copy of a real world: 6 chunks written, 374 kept, 552 before
and after, no temporary left behind.
Nothing stopped a RuntimeException reaching Minecraft. The mixins inject at the
tail of vanilla's packet handlers and the event registrations run inside the
client's own tick and connection handling, so anything escaping unwound into
code that has no idea what this mod is and took the client with it -- and
onBlockApplied, which calls into the level and two caches, had no guard at all.
The seam is the right place for one, so every dispatch point goes through it and
any future one will too. Errors are not caught: an OutOfMemoryError is not this
mod's to absorb, and pretending to carry on after one hides the only evidence.
A stray file in transactions/ made every Open fail forever, from every command,
with no way to reach fsck to find out why. A desktop.ini, a .DS_Store or a cloud
sync conflict copy was enough, and none of them says anything about whether the
transactions are sound. A file this package did not write is not a transaction.
transfer.Receive read a peer's bundle.json whole into memory whatever its size,
while internal/bundle caps four dimensions on the adapter path -- which is the
less untrusted of the two, since those bundles were written by a mod on the same
machine. Both it and each record are bounded now.
Three screens reported a failure as an absence. An unreadable recordings folder
came back as zero counts, so the play screen said "Nothing new since last time"
about a directory it had failed to open, while the import screen given the same
directory said so honestly. A failed list of moments read as "Nothing recorded
for this server. Play and bring in some recordings" -- advice for a situation
that was not theirs, about an answer that never arrived -- and on the world
screen the moment chooser simply vanished, taking the one thing that makes this
different from a world downloader with it. And a failed import left its button
disabled and still reading "Bringing it in...", because it lives in the screen's
footer and nothing else put it back.
0 commit comments