|Summary:||Capital letters sometimes converted to lowercase when accessing vfat partitions|
|Product:||[Fedora] Fedora||Reporter:||Mitchell Keith Bloch <bazald>|
|Component:||kernel||Assignee:||Alexander Viro <aviro>|
|Status:||CLOSED INSUFFICIENT_DATA||QA Contact:||Brian Brock <bbrock>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-05-05 14:23:55 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Mitchell Keith Bloch 2005-04-20 21:46:47 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Description of problem: When files are copied to vfat partitions, capital letters will occasionally be discarded. The letters *may* still appear to be capitalized, but will not always remain that way after subsequent reboots. While this is usually not crippling, in some cases it is (e.g. copying video files to a PSP). Version-Release number of selected component (if applicable): How reproducible: Sometimes Steps to Reproduce: 1. Copy a file with capital letters in the filename to a vfat partition. 2. Run 'ls' and see if the filename is still capitalized. 3. If it appears so, reboot and see if they still appear capitalized. Actual Results: In some cases, capital letters are replaced with lowercase letters. In other cases not. When they are replaced, it is possible to erase the existing files and to try again, but the letters will once again be converted in the same way. Expected Results: Capital letters should be preserved. Additional info: This problem has existed for me for a long time, but has not crippled anything I've tried to do until now.
Comment 1 Dave Jones 2005-07-15 18:17:05 UTC
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
Comment 2 Mitchell Keith Bloch 2005-07-25 04:58:03 UTC
Unfortunately, I no longer have a computer running Fedora Core. I can tell you a few more things however. The bug persisted in Fedora Core 4 shortly after its release. (I haven't used it since.) And the bug seems more severe when using the 'cp' command than when using the 'dd' command. Why this is the case, I do not know. Also, in the case of the PSP, it seems to have an additional error of truncating files when connected directly via a usb cable. That seems inexplicable to me, but can be avoided by using a memory stick reader/writer rather than the PSP itself. Sorry if I cannot be of more help, but the only computer I have available to install Fedora Core on, ironically, is built on the KT7-Raid mobo, and hence no longer has working USB ports.
Comment 3 Dan Carpenter 2005-07-26 04:39:37 UTC
VFAT is windows stuff. vfat has 2 filenames, the long one and the short one. The short one is not case sensitive. The type of filename that gets displayed is an option you can pass to `mount`. Type `man mount` and look for the vfat section. Basically this isn't a bug per se.
Comment 4 Mitchell Keith Bloch 2005-07-26 06:01:50 UTC
I read through those options quite a while ago, but there clearly is some bug in the way that filenames are set as files are copied to a vfat partition. My understanding is that mixed case filenames can be used and stored as such, but when accessing a file that already exists (reading/overwriting), the case is irrelevant. However, the Linux vfat driver seems not to store mixed case filenames correctly with any settings that I have used when using a regular 'cp' to copy a file with an uppercase filename. However 'dd' works just fine. As I have said, the only time that it has critically affected anything is when writing files for use on a PSP. For some reason, the PSP absolutely requires names to be stored as upper case (at least for video files). My guess is that they were lazy in writing the driver and did not bring it fully up to specifications.
Comment 5 Dan Carpenter 2005-07-26 07:13:00 UTC
If you want you can test with a loop back device. dd if=/dev/zero of=foo bs=1M count=32 mkfs.vfat foo mkdir bar mount -o loop foo bar [fiddle with files] umount bar mount -o loop foo bar [check to see if the file names are preserved] umount bar We really need a specific filename and the command you used to create the filename before we can debug this. The vfat stuff is wierd and it sometimes looks buggy even when it's working correctly. For example: root@box:/tmp/bar# touch foo bar Bar Baz NOODLE root@box:/tmp/bar# ls Baz bar foo noodle root@box:/tmp/bar# Only the case for 'Baz' is preserved.
Comment 6 Mitchell Keith Bloch 2005-12-07 20:48:45 UTC
I'm using Ubuntu at the moment, but I can test this in FC4 again in a week. I get the same result when using a loopback device as you suggest. However, when I use an external HD, formatted vfat, I get completely different results: root@box:/media/EXTERNAL$ touch foo bar Bar Baz NOODLE touch: cannot touch `Bar': File exists root@box:/media/EXTERNAL$ ls bar Baz foo NOODLE root@box:/media/EXTERNAL$
Comment 7 Dave Jones 2006-01-16 22:33:21 UTC
This is a mass-update to all currently open Fedora Core 3 kernel bugs. Fedora Core 3 support has transitioned to the Fedora Legacy project. Due to the limited resources of this project, typically only updates for new security issues are released. As this bug isn't security related, it has been migrated to a Fedora Core 4 bug. Please upgrade to this newer release, and test if this bug is still present there. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. Thank you.
Comment 8 Dave Jones 2006-02-03 05:35:39 UTC
This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you.
Comment 9 John Thacker 2006-05-05 14:23:55 UTC
Closing per previous comment.