Hide Forgot
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: Always 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:
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