Bug 192541 - vfat filesystem ignores the iocharset option
Summary: vfat filesystem ignores the iocharset option
Keywords:
Status: CLOSED DUPLICATE of bug 181963
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 5
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-05-20 10:11 UTC by Andrew Zabolotny
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-05-21 17:27:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
A tiny VFAT image with files/directories using Cyrillic (804 bytes, application/x-bzip2)
2006-05-20 10:11 UTC, Andrew Zabolotny
no flags Details

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 ***


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