Skip to content

Ticket #4861: add extension-based fallbacks for handling JAR and WAR files to mc.ext #4862

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.

Sign up for GitHub

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

Open
gerardbosch wants to merge 1 commit into
base: master
Choose a base branch
from
+7 −1
Open

Ticket #4861: add extension-based fallbacks for handling JAR and WAR files to mc.ext #4862

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion misc/mc.ext.ini.in
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1159,12 +1159,18 @@ Type=\\(Zip archive
Open=%cd %p/uzip://
View=%view{ascii} @EXTHELPERSDIR@/archive.sh view zip

[jar]
[jar-war-by-type]
Type=\\(Java (Jar file|archive) data \\((zip|JAR)\\)\\)
Copy link
Contributor

@ossilator ossilator Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

based on the addition of .war handling below, it would seem logical to add it here as well, or does no file variant recognize these as anything other than a regular zip archive?

actually, what are the files recognized as? you're not saying in the commit message.

the idea behind using content based detection is to catch files with non-standard extensions (for .jars, that may be modules in some applications). falling back to extension based detection is basically admitting defeat ...

Copy link
Member

@zyv zyv Jan 31, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I understand, wars are nothing other than jars, only meant to be uploaded to the application servers, so file output would be the same for both. In this sense, they have always been implicitly supported, or at least they should have been.

Given a number of recent posts to #4862 tickets, however, I think indeed it's time to admit defeat and add extension-based fallbacks. It seems that the problem is that even though we are now correctly matching on the file output, the utility itself is unreliable and often enough doesn't detect the correct type.

Copy link
Contributor

@ossilator ossilator Feb 1, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.wars contain additional metadata, so they could be detected separately.

i'd really like to see the exact status quo documented (in the commit message), so it's obvious what is being worked around and that this is the only reasonable way to do it.

Copy link
Member

@zyv zyv Feb 1, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.wars contain additional metadata, so they could be detected separately.

Maybe, but the file tool doesn't (currently) include any such provisions. I did search the source for both "jar" and "war".

i'd really like to see the exact status quo documented (in the commit message), so it's obvious what is being worked around and that this is the only reasonable way to do it.

I've updated the commit message. I think it's good enough now.

TypeIgnoreCase=true
Open=%cd %p/uzip://
View=%view{ascii} @EXTHELPERSDIR@/archive.sh view zip

[jar-war-by-regex]
Regex=\\.[jw]ar$
RegexIgnoreCase=true
Open=%cd %p/uzip://
View=%view{ascii} @EXTHELPERSDIR@/archive.sh view zip

[apk]
Type=Android package \\(APK\\)
TypeIgnoreCase=true
Expand Down
Loading