Red Hat Bugzilla – Bug 129631
FAT32 filesystem corruption when using directories with extended characters
Last modified: 2015-01-04 17:08:37 EST
Description of problem:
1) I mounted my FAT32 volume on my Win2K dual-boot machine:
"mount /dev/hda dos -o uid=user,gid=user"
2) I mounted a SAMBA filesystem
"mount //server/share samba -o ro,user=roshare"
3) Run my program. My program traverses the directory tree in both
the SAMBA volume and the FAT32 volume and makes sure the two contain
exactly the same files and directories. If there are files or folders
in the source that do not appear in the destination (or binary
comparison fails) then the files (and/or folders) are copied from the
source to the destination. When the program run is complete, the
FAT32 directory tree should be an exact copy of the SAMBA tree.
My program runs into problems when using folder names with extended
characters (like accented characters). I use readdir() to get
filenames (which I store in a char array) and then do a mkdir() to
create the folders. I use fread() and fwrite() to copy the files.
I observed the problem in the following way:
A comparison between the same folder name on the SAMBA and the FAT32
volumes failed (even though the names were the same to Win2K),
prompting my program to create a new folder with the name retrieved
from the SAMBA share.
When the directory was created, all the extended characters were
replaced with "?". After some time, the FAT32 volume started behaving
strangely, giving I/O errors on writing files and read only device
errors, when it was clearly mounted rw. Unmounting the FAT32 volume
and remounting it makes the problem go away. I don't know how many
folders/files it takes before the problem reappears as this is a
batch program copying tens of thousands of files and thousands of
I have been running this program under Cygwin for many months without
problem, so I rebooted into Win2K to run the program again and that
is when I noticed the filesystem corruption. When Win2K repaired the
disk, it complained about invalid allocation units for each of the
folders in question and all the files in each folder were lost.
As this is a slave machine that is synchronizing to a file server, I
tried repeating the problem and was able to get filesystem corruption
each time (but I couldn't tell if the same folders or different
folders were lost each time).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
File system corruption. Directory strings compare as not equal on
FAT32 and SAMBA shares when they should be identical.
No filesystem corruption, at least.
Marking bug as high priority as I get file system corruption.
I do not know how related is my problem with your bug report but using
option utf8 helped me with non-US-ASCII characters.
BTW Maybe vfat filesystem type more suitable than dos for FAT32
I missed one word - there should be "_is_ more suitable".
Hi, I'm having a similar or the same problem under FC2. I have a USB
drive formatted FAT32. When connected to XP or OSX I can create a
folder with an umlat-o in the name (BjÃ¶rk). This folder also exists
on a local drive (ext3) and is shared correctly via samba. When I try
to copy the folder from the ext3 drive to the fat32 drive (mounted
vfat) the copy fails. When I copy the folder via samba on osx or xp
it copys correctly. when I mount the drive back on FC2 and look at
the folder name the umlat-o is replaced by a "?" character.
I don't understand the comment to try UTF8, this does not seem to be a
mount option for vfat.
> When I try to copy the folder from the ext3 drive to the fat32 drive
(mounted vfat) the copy fails.
Does option "quiet" helps?
> I don't understand the comment to try UTF8, this does not seem to be
a mount option for vfat.
yum install kernel-doc
"utf8=<bool> -- UTF8 is the filesystem safe version of Unicode that
is used by the console. It can be be enabled for the
filesystem with this option. If 'uni_xlate' gets set,
UTF8 gets disabled."
Without that option I'm not able to see Polish chatacters (Ä
Right now I have something like this in the /etc/fstab file:
/dev/hda1 /mnt/FreeDOS vfat
any better with the 2.6.9 update ?
The test machine has been switched to FC3, with:
and the problem seems to be somewhat fixed. I can no longer get
corruption on the FAT32 volume by copying directories with UTF8
names, but mkdir calls fail with "Invalid argument" when trying to
create a directory with extended characters in the name. This
means "cp -r ~/dir1 ~/dir2" will fail on any (sub)directories with
extended characters in the name.
If I mount the FAT32 volume with "-o utf8" the problem seems to
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat. The Fedora legacy project will be producing further kernel
updates for security problems only.
If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.