Bug 120697 - (FS VFAT)vfat case sensitivity problems
(FS VFAT)vfat case sensitivity problems
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
: 120765 (view as bug list)
Depends On:
Blocks: 121529
  Show dependency treegraph
Reported: 2004-04-12 23:15 EDT by Len Trigg
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version: RHEL4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-06-22 15:43:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Script demonstrating the problem (693 bytes, text/plain)
2004-04-12 23:16 EDT, Len Trigg
no flags Details

  None (edit)
Description Red Hat Bugzilla 2004-04-12 23:15:10 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312

Description of problem:
When I mount a vfat filesystem and create files, the case of the files
changes after creation. I will attach a script demonstrating the
problem. This works fine on a redhat 9 machine.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run the attached script (you probably need to be root for the mount
to work)

Actual Results:  Test script fails.

Expected Results:  Test script should pass.

Additional info:
Comment 1 Red Hat Bugzilla 2004-04-12 23:16:16 EDT
Created attachment 99350 [details]
Script demonstrating the problem
Comment 2 Red Hat Bugzilla 2004-04-16 06:35:31 EDT
*** Bug 120765 has been marked as a duplicate of this bug. ***
Comment 3 Red Hat Bugzilla 2004-04-16 16:46:57 EDT
fyi - ia64 kernel.org 2.6.6rc1 doesn't suffer from this problem.
Comment 4 Red Hat Bugzilla 2004-04-21 15:23:29 EDT
I changed the platform from i686 to all because I'm seeing it on ia64.
Comment 5 Red Hat Bugzilla 2004-05-10 16:18:23 EDT
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
Comment 6 Red Hat Bugzilla 2004-05-10 18:54:34 EDT
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
Comment 7 Red Hat Bugzilla 2004-05-20 17:16:18 EDT
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. 
Comment 8 Red Hat Bugzilla 2004-05-23 17:46:01 EDT
This workaround does the trick for me -- thanks!
Comment 9 Red Hat Bugzilla 2004-05-26 15:16:34 EDT
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. 
Comment 10 Red Hat Bugzilla 2004-05-26 16:18:56 EDT
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. 
Comment 11 Red Hat Bugzilla 2004-05-26 18:03:08 EDT
I have sent an email about it.
Comment 12 Red Hat Bugzilla 2004-06-04 11:59:38 EDT
any updates on this?
Comment 13 Red Hat Bugzilla 2004-06-15 13:03:12 EDT
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). 
--- 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 
-       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, 
+                               return 1; 
+       } 
        return 0; 
Comment 14 Red Hat Bugzilla 2004-06-21 10:55:50 EDT
The fix for this problem is now in Linus' bk tree.  I'll close this 
bug when the fix makes it into RHEL4. 
Comment 15 Red Hat Bugzilla 2004-06-22 15:43:52 EDT
Fixed upstream, in Rawhide and RHEL4 now. 

Note You need to log in before you can comment on or make changes to this bug.