Bug 120697 - (FS VFAT)vfat case sensitivity problems
Summary: (FS VFAT)vfat case sensitivity problems
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
: 120765 (view as bug list)
Depends On:
Blocks: 121529
TreeView+ depends on / blocked
Reported: 2004-04-13 03:15 UTC by Len Trigg
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Fixed In Version: RHEL4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-06-22 19:43:52 UTC
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-13 03:16 UTC, Len Trigg
no flags Details

Description Red Hat Bugzilla 2004-04-13 03:15:10 UTC
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-13 03:16:16 UTC
Created attachment 99350 [details]
Script demonstrating the problem

Comment 2 Red Hat Bugzilla 2004-04-16 10:35:31 UTC
*** Bug 120765 has been marked as a duplicate of this bug. ***

Comment 3 Red Hat Bugzilla 2004-04-16 20:46:57 UTC
fyi - ia64 kernel.org 2.6.6rc1 doesn't suffer from this problem.

Comment 4 Red Hat Bugzilla 2004-04-21 19:23:29 UTC
I changed the platform from i686 to all because I'm seeing it on ia64.

Comment 5 Red Hat Bugzilla 2004-05-10 20:18:23 UTC
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 22:54:34 UTC
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 21:16:18 UTC
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 21:46:01 UTC
This workaround does the trick for me -- thanks!

Comment 9 Red Hat Bugzilla 2004-05-26 19:16:34 UTC
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 20:18:56 UTC
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 22:03:08 UTC
I have sent an email about it.

Comment 12 Red Hat Bugzilla 2004-06-04 15:59:38 UTC
any updates on this?

Comment 13 Red Hat Bugzilla 2004-06-15 17:03:12 UTC
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 14:55:50 UTC
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 19:43:52 UTC
Fixed upstream, in Rawhide and RHEL4 now. 

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