-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make UnionPath behave as paths from ZipFileSystem do. #26
base: main
Are you sure you want to change the base?
Conversation
I did some fixes to the
|
The specific crash provided uses an optional chain that defaults to the string |
Testing procedure is setup and completed. The additional endpoint in #20 mentioned to get the proper paths of a mod needs to be added later. |
I suspect that the performance tweaks have completely invalidated this PR. Can you re-evaluate if this is still appropriate? |
I just merged the tests from this PR (which assert that UnionPath behaves the same as JarPath) with the performance tweaks and some of them still fail. So yes, it is still appropriate, ill update it to resolve the conflicts. |
@marchermans is this still relevant?? |
Not that I know of |
If it is still relevant to mimic the behaviour of |
# Conflicts: # src/main/java/cpw/mods/jarhandling/impl/Jar.java # src/main/java/cpw/mods/niofs/union/UnionFileSystem.java
This PR is included in the 1.19 milestone. I guess that means it’ll be merged right before 1.19, right? |
This changes the behaviour of union paths to match the behaviour from zip paths. To ensure this, all path tests are first run against a zip file system and it is asserted that they don't fail.
This will most likely break modlauncher and forge
Also the tests for the
relativize
method were moved fromTestUnionFS
toTestUnionPath
.