FabricMC
Failure to delete temporary remapping file for any nested JAR in development environment
Description
I recently converted my development environment from 0.15.0 to 0.15.9. Upon doing so I noticed that my console was spammed with warnings from the loader whenever I ran the game. Further research showed that this specifically happens with any JAR that was nested within another mod. This is most prominent with FAPI due to it's heavy use of this feature, but not exclusive to it.
Logs
https://mclo.gs/Wi8ko3p
Reproduction
- Create an empty Fabric mod project (must use Fabric Loader >= 0.15.4)
- Add a mod to the run directory which utilizes nested JARs
- Run the game and observe the warnings during startup
- Navigate to
.fabric/tmp/in your run directory and observe the temporary files which were not deleted
Through some initial triage, 0.15.4 seems to be the version that this started happening.
From looking through the commits b2608bb is the likely candidate. My working theory is that the new version of TinyRemapper has the temporary JARs open after the remapping is supposed to be finished. No idea why this only happens with a manually added FAPI though.
While that commit is the problematic one, it turns out TinyRemapper isn't at fault here.
The RuntimeModRemapper#requiresMixinRemap(Path) method is leading to the creation of JarURLConnection to read the manifest from the JAR. These, by default, make use of a cache as described here. This is what is keeping the temporary file open and leading to the deletion failing.
Fixing the issue is as simple as turning the cache on the connection off in Manifest#readManifest(URL). This can be achieved with the following line of code: connection.setUseCaches(false);
Why this only occurs under the very specific circumstances and not generally is unknown to me. I am also not particularly satisfied with the solution I have so far and am going to look into what else can be done.
Very intresting, thanks a lot for digging into this. It is indeed weird why we havent seen this before, as a lot of existing code used this. 🤔
After some further experimentation - this has nothing specifically to do with FAPI either. It appears to affect any JAR loaded as a nested JAR through a fabric.mod.json. The most notable and extreme example of this is FAPI, but I was able to reproduce this with Iris and CIT Resewn who also make use of nested JARs. I will update the issue to reflect this discovery.
Furthermore, I am unable to reproduce this outside of a development environment. However, I do not understand Fabric Loader nearly well enough to understand why this is the case,
Side note: turns out the run/.fabric/tmp/ folder of my main project was roughly ~1GB due to these failed deletions ever since the upgrade. I had never actually checked and assumed that the console spam was the worst of it. It might be worth simply removing the whole directory before the Loader begins remapping as it does not seem to ever attempt to reuse these files anyway. We can discuss this further whenever I get around to making a pull request.