Lower/uppercase of files with very short names are not correctly handeled about smali

[JesusFreke]

Comment #1 originally posted by JesusFreke on 2010-06-21T00:29:15.000Z:

Forgot to say that I did this on a Windows 7 64-bit machine.

[JesusFreke]

Comment #2 originally posted by JesusFreke on 2010-06-21T00:54:53.000Z:

Hmmmm. That looks really odd. Are the cases of the class names themselves (in the .class directive at the top of the file) affected as well? I would assume so, but can you doublecheck?

I'll take a look at it, thanks for the bug report :)

[JesusFreke]

Comment #3 originally posted by JesusFreke on 2010-06-21T01:22:02.000Z:

It seems that class names are also affected.

"h.smali" and "H.smali" start both like this:
.class public final Lcom/google/android/apps/uploader/h;

"ManagerActivity.smali" like this:
.class public Lcom/google/android/apps/uploader/ManagerActivity;

I know from logcat that a class "H" (among others that could not be found) was searched and could not be found:
E/dalvikvm( 289): Could not find class 'com.google.android.apps.uploader.H' ...

I also noticed when I open MediaUploader.odex in an text editor that I can find both Strings:
$Lcom/google/android/apps/uploader/H;
and
$Lcom/google/android/apps/uploader/h;

So, probably smali/baksmali is correct, but windows can not distinguish lower & uppercase files with the same name... smali/baksmali should print out a warning or error message in this case.

I´ll try tomorrow in a linux environment.

[JesusFreke]

Comment #4 originally posted by JesusFreke on 2010-06-21T08:03:52.000Z:

Yeah, I've got several issue reports about that problem, e.g.:

http://code.google.com/p/android-apktool/issues/detail?id=28

Code obfuscators produce classes like "a" and "A", but Windows can't store both of these files. Really annoying thing, but I think this is a problem of Windows and baksmali shouldn't do some dirty hacking to fix this. If you would have jar file with that obfuscated app, then even just unpacking it would be too much for a crappy Windows :-/

[JesusFreke]

Comment #5 originally posted by JesusFreke on 2010-06-21T12:51:42.000Z:

Hmm. Well, smali doesn't really care what the actual name of the file is. It takes the class name from the .class directive. Maybe I can have baksmali use some sort of naming scheme to resolve these conflicts on case insensitive file systems.

[JesusFreke]

Comment #6 originally posted by JesusFreke on 2010-06-21T13:25:13.000Z:

Maybe smali/baksmali can just stop with an error message if a file is overwritten with a file that is called the same but with different capitalization. And "-I" (or a new flag) ignores these errors.

Or more simple: Just a warning if a file is overwritten.

A naming scheme sounds good, but the results under windows & linux should be the same, else it could be too confusing.

[JesusFreke]

Comment #7 originally posted by JesusFreke on 2010-06-22T04:12:39.000Z:

I agree. The results under linux are "it works". I think we need the same result under windows :)

[JesusFreke]

Comment #8 originally posted by JesusFreke on 2010-08-02T01:17:29.000Z:

This has been fixed in r784. if baksmali detects a case insensitive file system, it will append a .2, .3, .4 etc. to the end of files and directories as needed, to prevent collisions.

So if there was a Lblah; and an LBLAH;, you would have a blah.smali and a BLAH.2.smali

[JesusFreke]

Comment #9 originally posted by JesusFreke on 2010-08-02T01:17:42.000Z:

<empty>