Bug 192541

Summary: vfat filesystem ignores the iocharset option
Product: [Fedora] Fedora Reporter: Andrew Zabolotny <anpaza>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED DUPLICATE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-05-21 17:27:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
A tiny VFAT image with files/directories using Cyrillic none

Description Andrew Zabolotny 2006-05-20 10:11:24 UTC
Description of problem:

The vfat module ignores the "iocharset" option and always assumes that UTF-8 is
used as system charset. Basically this means that any files/directories are
unusable if your system charset differs from UTF-8. The "codepage" option works
for short filenames (without long Unicode equivalents) which is correct.

Version-Release number of selected component (if applicable):

2.6.16-1.2111_FC5

How reproducible:

Always

Steps to Reproduce:
1. Unpack the attached file vfat-img.bz2. This is a tiny VFAT image made
manually with some files/directories using codepage 866 (cyrillic).
2. Mount it like this:
   mkdir tmp
   mount vfat-img /mnt/tmp -o loop,codepage=866,iocharset=cp1251
3. Execute:
   LANG=ru_RU.KOI8-R ls -la /tmp >list.txt
4. Compare resulting list.txt with the file tmp/file-list.txt.
  
Actual results:

The file names in list.txt are in UTF-8, while the file names in
tmp/file-list.txt are in KOI8-R.

Expected results:

The file list in both lists are in the same encoding.

Comment 1 Andrew Zabolotny 2006-05-20 10:11:24 UTC
Created attachment 129722 [details]
A tiny VFAT image with files/directories using Cyrillic

Comment 2 Andrew Zabolotny 2006-05-21 17:27:17 UTC
Actually after looking at kernel SRPM it seems that this bug is due to the
incorrectly resolved bug #181963.

Closing this bug.


*** This bug has been marked as a duplicate of 181963 ***