Skip to content
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

Exporting to HFS+ (macOS) should mind case-insensitivity of the filesystem #158

Closed
yotams opened this issue Feb 1, 2017 · 8 comments
Closed

Comments

@yotams
Copy link

yotams commented Feb 1, 2017

When exporting a JAR with 2 classes, aA and aa, the first will be exported to "aA.java". Then, jadx will try to export aa to "aa.java". HFS+ is a case insensitive filesystem, so the content of the latter will overwrite the former. I guess this would also be an issue with Windows filesystems (NTFS/FAT).

@dannyZhou
Copy link

It is impossible to compile an apk when project both have aA.java and aa.java in same directory when filesystem is a case insensitive.

To get an apk about this. I think we have two methods.

  1. Using filesystem witch is a case sensitive such as HFS+(Case Sensitive Version of Mac), Ext4 in linux etc.
  2. Upload apk to a apk protect website to get a protected apk. Some protect website support confuse class names.

Solution:

  • You can split mac HFS disk, create a new HFS support case sensitive. Format and mount it to a point you like. Export files to this disk.
  • Install a linux such ubuntu archlinux etc, handle this apk in linux. Using extX format of disk.
  • Using docker. (Never tried, I don't know if it is workable.)

My English is poor, sorry.

@skylot
Copy link
Owner

skylot commented Jan 15, 2018

I can add dynamic detection for case insensitive filesystem. Current check work only for Windows and Linux (use apache common-io library)

@skylot
Copy link
Owner

skylot commented Jan 18, 2018

Can anyone check this issue using latest unstable version?
I hope it will work, but I can't test it myself because I don't have a Mac computer

@bagipro
Copy link
Collaborator

bagipro commented Mar 25, 2019

@skylot
I use macOS and I didn't meet such errors within last year

@bagipro bagipro closed this as completed Mar 25, 2019
@jpstotz
Copy link
Collaborator

jpstotz commented Apr 8, 2019

@skylot: I noticed that class renaming is now done automatically. Is there a way to disable this? Because if you don't export the sources you don't need this function.
Furthermore if you are searching for a specific class by name you won't find it as it has been renamed. This may be unexpected from a user perspective.

@skylot
Copy link
Owner

skylot commented Apr 8, 2019

@jpstotz I see, but now renaming can't be disabled, we need to add the option for that.
And there are many "renaming" types besides deobfuscation:

  • to support system case sensitivity
  • to make valid java identifiers (to make code compilable)
  • to remove not "printable" characters
    So this is a good question of how to make this "renaming" option.

@jpstotz do you need the option to disable all such renaming or only some of them?

@jpstotz
Copy link
Collaborator

jpstotz commented Apr 8, 2019

@skylot

From my perspective I don't see a point why someone would like to disable the renaming because of non-printable characters - therefore I would assume that this can be always active without problems.

Support system case sensitivity and make valid Java identifiers are options you usually only need in case you use the export function (unless you copy parts of the generated Java code via clipboard). Therefore it would be good to have an option for disabling/enabling these two renaming reasons.

@skylot
Copy link
Owner

skylot commented Apr 8, 2019

@jpstotz I open an issue with description for your request: #570

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants