Bug 120697

Created attachment 99350 [details]
Script demonstrating the problem

*** Bug 120765 has been marked as a duplicate of this bug. ***

fyi - ia64 kernel.org 2.6.6rc1 doesn't suffer from this problem.

I changed the platform from i686 to all because I'm seeing it on ia64.
fyi.

kernel.org 2.6.6, configured like a redhat kernel would be, 
seems to have this problem now too.  I had previously pointed out
that 2.6.6rc1 didn't seem to have the problem but the problem seems
to have found its way in to the 2.6.6 release.  -Erik

Have you reported this upstream, or would you like me to?

I wonder if it is possible to test this on different
kernels/configurations easily without having to reboot my running
machine (e.g.: run the test script within usermode linux?).

I haven't done either of these before, but would be willing to have a
crack at it, since this bug is preventing me from syncing my iPod on my
machine.  Comment #3 led me to believe that I'd just have to wait a
couple of weeks for a new kernel rpm, but now it seems that isn't the
case.

I was able to work around this by mounting with the 
'shortname=mixed' option.  Does that work for you?  I'm still 
digging around in the fs code to see what changed between 2.6.6-rc1 
and 2.6.6 proper. 
 
Jesse 

This workaround does the trick for me -- thanks!

This only occurs when utf8 is selected as the default charset.  
Mounting with iocharset=iso8859-1 also works around the problem.  
fs/fat/inode.c:1025 has a FIXME regarding case and utf8. 
 
Jesse 

Len, can you bring this up on lkml and with the FAT maintainer?  It 
looks like it's a configuration thing, but since most people are 
using utf8 these days it seems worth fixing. 
 
Thanks, 
Jesse 

I have sent an email about it.

any updates on this?

I've asked the maintainer a few questions: 
  o is utf8 not supposed to do upper/lowercase conversion?  
nls_utf8.c makes it appear so 
  o is special casing utf8 in FAT directory lookups the right thing 
to do?  it might be that this is the expected behavior 
 
If the answer to both questions is 'yes', then a patch like this 
would work.  I've sent it to the maintainer in the likely event that 
he'd like something a bit cleaner (like fixing up the callers or 
doing the check in fat_tolower). 
 
Jesse 
 
--- linux-2.6.7-rc3/fs/fat/dir.c        2004-06-07 
15:13:36.000000000 -0400 
+++ linux-2.6.7-rc3.fatutf8/fs/fat/dir.c        2004-06-15 
12:57:58.910858983 -0400 
@@ -19,6 +19,7 @@ 
 #include <linux/dirent.h> 
 #include <linux/smp_lock.h> 
 #include <linux/buffer_head.h> 
+#include <linux/ctype.h> 
 
 #include <asm/uaccess.h> 
 
@@ -144,9 +145,20 @@ 
 fat_strnicmp(struct nls_table *t, const unsigned char *s1, 
                                        const unsigned char *s2, int 
len) 
 { 
-       while(len--) 
-               if (fat_tolower(t, *s1++) != fat_tolower(t, *s2++)) 
-                       return 1; 
+        int utf8; 
+ 
+       utf8 = !strcmp(t->charset, "utf8"); 
+ 
+       if (utf8) { 
+               while(len--) 
+                       if (tolower(*s1++) != tolower(*s2++)) 
+                               return 1; 
+       } 
+       else { 
+               while(len--) 
+                       if (fat_tolower(t, *s1++) != fat_tolower(t, 
*s2++)) 
+                               return 1; 
+       } 
 
        return 0; 
 

The fix for this problem is now in Linus' bk tree.  I'll close this 
bug when the fix makes it into RHEL4. 
 
http://linux.bkbits.net:8080/linux-2.5/cset%
401.1764.1.6?nav=index.html|ChangeSet@-4d 
 
Jesse 

Fixed upstream, in Rawhide and RHEL4 now. 
 
Jesse