Bug 155502 - Capital letters sometimes converted to lowercase when accessing vfat partitions
Capital letters sometimes converted to lowercase when accessing vfat partitions
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Alexander Viro
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-20 17:46 EDT by Mitchell Keith Bloch
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-05 10:23:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mitchell Keith Bloch 2005-04-20 17:46:47 EDT
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 14:17:05 EDT
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 00:58:03 EDT
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 00:39:37 EDT
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 02:01:50 EDT
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 03:13:00 EDT
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 15:48:45 EST
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 17:33:21 EST
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 00:35:39 EST
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 10:23:55 EDT
Closing per previous comment.

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