Backups

Backups

235k Downloads

Backups often fail to restore when using command while MineTogether mod is present, causing world corruption

floral-qua-floral opened this issue ยท 3 comments

commented

Hello! Long story short, I'm using the old React mod to automatically run "/backupsmod restoreworld 1" on player death to forcibly reload the most recent backup. I'm making this initial report in case the report or the logs could be useful, but since the environment the issue is occuring in is very heavily modded, I'll also be doing further testing to see if I can narrow it down in order to try and replicate it in a cleaner environment. Unless this report turns out to be good enough already for the issue to be addressed, then I'll be coming back to add my findings once I narrow down the specific cause.

The issue I'm receiving is that when automatically reloading backups, there seems to be an occasional problem in which a world will fail to reload its backup on the player's death. Rather than sending me to the title screen so they may re-enter the world, a red screen appears saying, "Unable to restore backup. The backup might be corrupted. Check logs for more details.". Pressing Cancel brings me to the title screen, however checking my singleplayer worlds list reveals it to be empty. The world directory is still present in my saves folder, so I assume it is just corrupted rather than deleted.

The issue appears to occur randomly. On some occasions the backup will fail and the world will be corrupted, even on my first death in a brand new world immediately after launching the game, while other times I will be successfully sent to the title screen to re-enter the world, which has been successfully restored to the desired backup. I have not been able to find anything in particular that affects the outcome of a death one way or the other yet. One thing I've noticed is that sometimes when a backup is successfully restored, VanillaFix will report several exceptions at once, however there is no crash. Other times, no exceptions occur. In either case, the world seems to reload fine. When a backup fails to restore, no exceptions are thrown and the game does not crash.

Three log files are attached. To create the logs I launched the game, generated a new Superflat world with a unique name, waited for my React script to initiate a world backup, and then allowed myself to be killed by Slimes to initiate a backup restore (I am using Superflat worlds because they generate quickly and they're easy to die in, however the issue does still occur in other world types), then quit the game as soon as I got a corruption. In the first two logs, first-death-corruption-1 and 2, the world is lost upon my first death. In the third log, one-successful-death, the world restores fine after the first death (no exceptions detected by VanillaFix), so I re-enter the world and die again. On my second death, the world is corrupted.
I've also attached .zip files of the three worlds that have been corrupted, just in case. I recognize that with all the mods currently active, entering the world is absolutely not feasible from your end, but I figured that there might be a clue as to what's going on in the world files, so it would be worth the minimal effort of including them.

Logs:
first-death-corruption-1.log (backup error @ line 51384)
first-death-corruption-2.log (backup error @ line 55481)
one-successful-death.log (first death @ line 51417, backup error @ line 54210)
Worlds:
first-death-corruption-1.zip
first-death-corruption-2.zip
one-successful-death.zip
As a quick note - I did take a peek into the logs myself, and found that it's reporting another program (another mod?) accessing pregenData.json. I removed the ChunkPregenerator mod and tried again as a fourth test, but the issue still occurred, and the log still says it is because of pregenData.json. If desired, I can upload that world and log file as well, but I assumed it would be redundant, as it'd be more or less identical to first-death-corruption-1 and 2 with one mod removed.

I intend to update this ticket with more information once I've uncovered more, but I figured the explanation/logs might be useful already, and I wanted to put this all down while it's still fresh in my head. What I am going to see if I can do is figure out whether this occurs with manually-performed backups through the restoreworld command or if it is specifically caused by initiating them automatically during death, and then I will try to cut out mods until I can narrow it down to a specific interaction between Backups and something else.

commented

From looking at the error I believe this is because some mod (MineTogether in this case, however there might be other mods that do this) is trying to read or modify a file in the world directory after the world has been closed down. On windows if you try to modify a file that's currently being read, then you'll receive an error. So if the world shuts down and then restores the backup, but while the backup is being restored another mod tries to read or modify some file in the world directory then the restore will fail. The reason the world is being corrupted is because my mod stops restoring the backup as soon as it encounters an error, leaving the world in a partially restored state.

I am not quite sure how to fix this bug, but for now at least I can prevent the world from being corrupted by making my mod not override the world directory before it has completely restored the backup. I'll release a new version tomorrow that fixes that, and try to figure out how to fix this bug entirely.

commented

I got lucky with my testing and found the problematic interaction relatively quickly - it looks like the issue occurs when Backups is loaded alongside MineTogether. The React mod does not seem to be relevant, as I'm able to replicate the bug by running the backup and restore commands manually.

A log file is included showcasing the issue in a much cleaner environment is attached below, as is the corrupted world in case it is of any use.

latest.log (backup error @ line 126)

Superflat Test New.zip (Note: I named it Superflat Test New but forgot to make it superflat. Don't mind that...)

commented

I just released version 1.5.2 which should kind of fix this. You'll still get an error when restoring, but the world won't be corrupted and the world should be restored properly. I also added a two second delay between the world closing and the world restoring so that should help. I'm leaving this open because I haven't entirely fixed it but at the very least your world shouldn't be corrupted.