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

[GoogleCodeExporter]

What seems to be the problem?

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

What is the exact smali/baksmali command that you ran?

see below

What version are you using?

Java(TM) SE Runtime Environment (build 1.6.0_19-b04)
Java HotSpot(TM) Client VM (build 16.2-b04, mixed mode, sharing)

and smali/baksmali 1.2.3

Please provide any additional information below: error messages, symptoms,
etc.

I deodexed MediaUploader.odex from a desire rom:
java -jar baksmali-1.2.3.jar -d framework -x MediaUploader.odex

outdir:
21.06.2010  02:00             9.114 A.smali
21.06.2010  02:00             2.399 aa.smali
21.06.2010  02:00             6.399 aB.smali
21.06.2010  02:00             1.398 aC.smali
21.06.2010  02:00               223 aD.smali
21.06.2010  02:00             1.713 aE.smali
21.06.2010  02:00               192 aF.smali
21.06.2010  02:00               930 aG.smali
...

This is correct!

Then I smali´d the outdir to produce out.dex:
java -jar smali-1.2.3.jar out

Then I baksmali´d out.dex again, because it produced tons of java exceptions 
on my device:
java -jar baksmali-1.2.3.jar out.dex

outdir:
21.06.2010  01:56             9.114 a.smali
21.06.2010  01:56             2.399 aA.smali
21.06.2010  01:56             6.399 ab.smali
21.06.2010  01:56             1.398 ac.smali
21.06.2010  01:56               223 ad.smali
21.06.2010  01:56             1.713 ae.smali
21.06.2010  01:56               192 af.smali
21.06.2010  01:56               930 ag.smali

Files with longer names seem not affected (e.g. 
ConnectivityBroadcastReceiver.smali).

Original issue reported on code.google.com by phd....@gmail.com on 21 Jun 2010 at 12:26

[GoogleCodeExporter]

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

Original comment by phd....@gmail.com on 21 Jun 2010 at 12:29

[GoogleCodeExporter]

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 :)

Original comment by JesusFr...@gmail.com on 21 Jun 2010 at 12:54

• Changed state: Accepted

[GoogleCodeExporter]

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.

Original comment by phd....@gmail.com on 21 Jun 2010 at 1:22

[GoogleCodeExporter]

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 :-/

Original comment by Brut.alll on 21 Jun 2010 at 8:03

[GoogleCodeExporter]

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.

Original comment by JesusFr...@gmail.com on 21 Jun 2010 at 12:51

[GoogleCodeExporter]

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.

Original comment by phd....@gmail.com on 21 Jun 2010 at 1:25

[GoogleCodeExporter]

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

Original comment by JesusFr...@gmail.com on 22 Jun 2010 at 4:12

[GoogleCodeExporter]

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

Original comment by JesusFr...@gmail.com on 2 Aug 2010 at 1:17

[GoogleCodeExporter]

Original comment by JesusFr...@gmail.com on 2 Aug 2010 at 1:17

• Changed state: Fixed