[BUG] Legacy config migration fails when rusherhack\legacy already exists, and default settings are written anyway (v2.0.8)

[preteritumthomsen-del]

First of all, thank you for RusherHack — it has become the client I use every day, and I really appreciate how much work goes into keeping it current. I hope this report is useful rather than a nuisance; please feel free to close it if I have misunderstood something.

A note on where this came from: I did not notice this myself at the time. An AI assistant went through my client logs and config directories with me afterwards and pieced together what had happened, which is why the report is as detailed as it is. I have verified the log excerpt and the file details below against my own machine. The only reason I am posting is to contribute something back and hopefully save someone else the confusion — there is no complaint here and nothing I need fixed for my own sake, since I have already recovered my settings.

Summary

On first launch of v2.0.8 in a game directory where an older rusherhack\config was already present, the client tried to migrate it into rusherhack\legacy\, the migration threw, and a fresh set of default settings was written to config\ anyway. The old configuration was not lost from disk, but from the running client's point of view it was simply gone, and nothing in-game indicated that anything had happened.

Environment

• RusherHack v2.0.8 (release channel)
• Minecraft 1.21.11, Fabric
• Windows 11, Java locale nb-NO

What happens

The migration step logs a single ERROR line and then loading continues as if nothing went wrong:

[2026-08-27 19:01:05] [INFO] Initializing rusherhack v2.0.8
[2026-08-27 19:01:06] [ERROR] Failed to migrate legacy rusherhack configs
java.io.FileNotFoundException: rusherhack\legacy (Ingen tilgang)
	at java.base/java.io.FileInputStream.open0(Native Method)
	at java.base/java.io.FileInputStream.open(FileInputStream.java:213)
	at java.base/java.io.FileInputStream.<init>(FileInputStream.java:152)
	at knot//com.google.common.io.Files$FileByteSource.openStream(Files.java:131)
	at knot//com.google.common.io.Files$FileByteSource.openStream(Files.java:119)
	at knot//com.google.common.io.ByteSource.copyTo(ByteSource.java:277)
	at knot//com.google.common.io.Files.copy(Files.java:325)
	at knot//com.google.common.io.Files.move(Files.java:498)
	at org.rusherhack.client.џ.<init>(џ.java:229)
	at org.rusherhack.client.џ.Ѫ(џ.java:193)
	at org.rusherhack.mixin.MixinHelper.b(MixinHelper.java)
	at org.rusherhack.mixin.MixinHelper.postGameStart(MixinHelper.java:183)
	at knot//net.minecraft.class_310.handler$dgj000$postStartGame(class_310.java:13637)
	at knot//net.minecraft.class_310.<init>(class_310.java:745)
	at knot//net.minecraft.client.main.Main.main(Main.java:234)
	at net.fabricmc.loader.impl.game.minecraft.MinecraftGameProvider.launch(MinecraftGameProvider.java:514)
	at net.fabricmc.loader.impl.launch.knot.Knot.launch(Knot.java:72)
	at net.fabricmc.loader.impl.launch.knot.KnotClient.main(KnotClient.java:23)

[2026-08-27 19:01:16] [INFO] rusherhack v2.0.8 finished loading.
[2026-08-27 19:01:16] [INFO] Loading configs...

(Small note in case it helps someone grepping for it: Ingen tilgang is just the Norwegian Java locale rendering of Access is denied — the message will read differently on other locales.)

What I believe is going on (my reading of the trace, not verified against the source)

com.google.common.io.Files.move() first attempts File.renameTo(). On Windows that fails when the destination already exists, so Guava falls back to Files.copy() — and copy() opens the source as a byte stream, which cannot work when the source is a directory. That produces the FileNotFoundException above. The trigger therefore seems to be simply that rusherhack\legacy\ already existed from an earlier run.

If that reading is right, the condition to reproduce would be:

1. Launch v2.0.8 once with an older config present, so rusherhack\legacy\ gets created.
2. Place an older config\ in the game directory again and launch a second time.
3. The migration throws, and config\ is populated with defaults.

Why it is easy to miss

The file sizes afterwards look almost identical, so at a glance it appears the migration succeeded:

File	After (defaults)	In legacy\ (mine)
hud.json	29 199 B	29 191 B
binds\modules.json	12 341 B	12 289 B

Comparing by index also does not work, because v2.0.8 added the AutoBreed module and every later entry shifts — a naive diff shows hundreds of false differences. Comparing by name is what finally made it clear.

In my case the defaults replaced 83 module settings and 7 keybinds (AntiAFK, AutoEat, AutoTrader, BaseFinder, ElytraFly, Freecam, FreeLook), along with the whole AutoTrader whitelist, the BaseFinder log, the theme, my ViewModel scale, and every Search alert/sound toggle on blocks, items and entities.

Workaround (for anyone who runs into this)

Close the game, copy rusherhack\legacy\config\* back over rusherhack\config\, and rename rusherhack\legacy to something else so the failing migration does not run again. Nothing is actually lost — it is all still sitting in legacy\.

Suggestion, offered gently

Would it be possible for the client to avoid writing defaults when the migration step has thrown? Even leaving the old config\ untouched and logging a line in chat would make the situation obvious, since as it stands the only clue is one ERROR line in the log file. Merging back into an existing legacy\ directory (or moving into a timestamped one, e.g. legacy-2) would also sidestep the renameTo failure entirely.

I searched the tracker for legacy, Failed to migrate, config reset and settings reset before opening this and did not find an existing report, but I may well have missed one — apologies if this is a duplicate. Happy to provide the full log file, both config directories, or test anything you would like me to try.

Thanks again for all the work on the client.