Re: [BUG] FAT broken in 2.6.7-bk15

Re: [BUG] FAT broken in 2.6.7-bk15

[Ali Akcaagac]

> But you didn't install these. So fatfs couldn't do what you specified,
> then fatfs logged it and returns error.
> 
> Looks like you want to the following config.
> 
> CONFIG_FAT_DEFAULT_CODEPAGE=850
> CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-15"

Right I figured this one out myself already (see the other mail to you earlier this morning). I only questionize whether having to do this "manually" is such a good idea and if it doesn't lead to misunderstanding (better explaination in my other mail too).

I recommend to have something like this:

check whether some default NLS and character encoding has been selected in default NLS option.

- If not select 437 and iso8859-1 automatically for msdos and also 'enable' these automatically in the default NLS setup.

- If something has been selected in the default NLS already then popup a submenu which only shows those that you already have selected in the default NLS setup. So you can chose between those you already have selected.

- If only utf-8 has been selected in default NLS previously then throw out a warning or something.

At least in any cases make sure that you MUST select something to get msdos and fat support compiled and working correctly so that cases like mine NEVER happens.

Re: [BUG] FAT broken in 2.6.7-bk15

[Ali Akcaagac]

> > Yeah here the .config snipplet. But I still wonder how this
> > influences mounting an msdos or vfat partition. Unfortunately I am
> > no expert in FAT related stuff but I assume that textual stuff
> > stored in a filesystem shouldn't affect mounting and unmounting. The
> > only thing NLS changes in a filesystem is special charakters for
> > filenames but it doesn't change the technical structure of the FS
> > itself so in worst case I only get some strange characters shown in
> > filenames.

> Do you have both nls_cp437 and nls_iso8859_1 modules loaded?

Good point. After doing a normal lsmod I only saw that "msdos" and "vfat" modules got loaded and no further language specific stuff. I then tried modprobing 'nls_cp850' and 'nls_iso8859_15' which got loaded fine but same issues. After reconfiguring the Kernel and >>>manually<<< adjusting the msdos part from 437 to 850 and iso8859-1 to iso8859-15 and reloading the msdos module everything worked as expected again. Although I do questionize whether the current changes are so optimal for the user. In the past and that's how I understood OGAWA Hirofumi the msdos driver got it's information from the big NLS submenu of the Kernel configuration and now it has been split out due to some people reporting problems when having select utf8. But having >>>manually<<< to adjust msdos to point to nls modules other than 437 and iso8859-1 is quite cumbersome and leads to misunderstanding. I did saw the changes to msdos when going through my configure process but I assumed that it automaticly handles 437 (as it pointed on default) and I wondered why it has been split out. But I now figured out that it's not loading an OWN module, it's only POINTING to a NLS module >>>by name<<< and that you need to make sure >>>manually<<< to either change it to the module you selected in the NLS submenu or to adjust the NLS submenu by adding the module which msdos refers by default.
It would be pretty nice to have this 'idea' being rethought a bit more so that it doesn't lead into confusion and missunderstandings.

Re: [BUG] FAT broken in 2.6.7-bk15

[Ali Akcaagac]

> > Ok after some further research I figured this out. My last working
> > version of the Linux Kernel was 2.6.7 which worked with my rescue
> > system. I now applied the bk* patches upwards to check which one caused
> > the issue and I figured that this happened between bk3 to bk4 (so the
> > problem occoured with the bk4 patch). The diskimage was created with
> > mtools 3.9.9 and worked perfectly before.

> Ah, my fault. I changed the handling of "codepage" options, but it wasn't
> mentioned on changelog at all. (Sorry, I didn't notice this changes.)
> 
> Now, the codepage option recognizes only real NLS codepage module.
> (It uses FAT_DEFAULT_CODEPAGE, not NLS_DEFAULT. And FAT_DEFAULT_CODEPAGE
> only recognizes the numbers.)
> 
> Previously, it recognized/loaded all NLS modules via CONFIG_NLS_DEFAULT,
> if it can't load the nls_cp437.ko or specified codepage.
> 
> But this is seriously wrong. For example, if fatfs using the
> nls_utf8.ko for codepage, it will store the wrong 8.3-alias to
> disk. (At least, windows can't read this. And several peoples reported
> this problem.)
> 
> Anyway, could you please check FAT_DEFAULT_CODE/FAT_DEFAULT_IOCHARSET
> and NLS_xxx in your .config.
> 
> Yes, this should be done automatically by config system. However...

Yeah here the .config snipplet. But I still wonder how this influences mounting an msdos or vfat partition. Unfortunately I am no expert in FAT related stuff but I assume that textual stuff stored in a filesystem shouldn't affect mounting and unmounting. The only thing NLS changes in a filesystem is special charakters for filenames but it doesn't change the technical structure of the FS itself so in worst case I only get some strange characters shown in filenames.

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-15"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

Re: [BUG] FAT broken in 2.6.7-bk15

[Jesse Stockall]

On Sun, 2004-07-04 at 18:11, Ali Akcaagac wrote:
> Yeah here the .config snipplet. But I still wonder how this influences mounting an msdos or vfat partition. Unfortunately I am no expert in FAT related stuff but I assume that textual stuff stored in a filesystem shouldn't affect mounting and unmounting. The only thing NLS changes in a filesystem is special charakters for filenames but it doesn't change the technical structure of the FS itself so in worst case I only get some strange characters shown in filenames.
> 

Do you have both nls_cp437 and nls_iso8859_1 modules loaded?

Jesse

-- 
Jesse Stockall <stockall@magma.ca>

Re: [BUG] FAT broken in 2.6.7-bk15

[OGAWA Hirofumi]

Ali Akcaagac <aliakc@web.de> writes:

> The only thing NLS changes in a filesystem is special charakters for
> filenames but it doesn't change the technical structure of the FS
> itself so in worst case I only get some strange characters shown in
> filenames.

No, it's very unuseful. Probably it can't lookup, and it has possible
of filesystem corruption if you write.

If you want to do it, just read/write the partition directly.


> CONFIG_FAT_DEFAULT_CODEPAGE=437
> CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"

You configured these, so fatfs will try to use it.

> # CONFIG_NLS_CODEPAGE_437 is not set
> CONFIG_NLS_CODEPAGE_850=m
> # CONFIG_NLS_ISO8859_1 is not set
> CONFIG_NLS_ISO8859_15=m

But you didn't install these. So fatfs couldn't do what you specified,
then fatfs logged it and returns error.

Looks like you want to the following config.

CONFIG_FAT_DEFAULT_CODEPAGE=850
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-15"
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: [BUG] FAT broken in 2.6.7-bk15

[Ali Akcaagac]

[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]

> > The recent changes in 2.6.7-bk15 broke FAT support. I am doing some
> > rescue backup systems here using tools like syslinux and mtools to
> > format a normal msdos disk (for el-torito). I figured out that after
> > creating and formating of these disks that it is impossible to mount
> > them with 'msdos' or 'vfat'.

> You may be able to check for yourself precisely which change caused
> trouble for you. The only very recent change is one that makes the
> kernel more permissive.

> Give details on what versions work for you, what versions don't.
> Give the exact error messages. Give the first few sectors of the
> filesystem that you cannot mount but can mount with an earlier kernel.

Ok after some further research I figured this out. My last working
version of the Linux Kernel was 2.6.7 which worked with my rescue
system. I now applied the bk* patches upwards to check which one caused
the issue and I figured that this happened between bk3 to bk4 (so the
problem occoured with the bk4 patch). The diskimage was created with
mtools 3.9.9 and worked perfectly before.

export MTOOLSRC=".mtools.conf"
echo "drive a: file=\"/tmp/bootflop.img\" mformat_only" > .mtools.conf
dd if=/dev/zero of=/tmp/bootflop.img count=5760 bs=512
mformat -t 80 -h 2 -s 36 A:
rm .mtools.conf

The diskimage was created that way for countless months without any
problems. You find the image as attachment. After bunzip'ing it you
receive a 2,88 mb file (don't worry about the tiny size now) with the
md5sum: dc27cfe332cf96238e80d148c9955b9e

[-- Attachment #2: bootflop.img.bz2 --]
[-- Type: application/x-bzip, Size: 231 bytes --]

Re: [BUG] FAT broken in 2.6.7-bk15

[OGAWA Hirofumi]

Ali Akcaagac <aliakc@web.de> writes:

> Ok after some further research I figured this out. My last working
> version of the Linux Kernel was 2.6.7 which worked with my rescue
> system. I now applied the bk* patches upwards to check which one caused
> the issue and I figured that this happened between bk3 to bk4 (so the
> problem occoured with the bk4 patch). The diskimage was created with
> mtools 3.9.9 and worked perfectly before.

Ah, my fault. I changed the handling of "codepage" options, but it wasn't
mentioned on changelog at all. (Sorry, I didn't notice this changes.)

Now, the codepage option recognizes only real NLS codepage module.
(It uses FAT_DEFAULT_CODEPAGE, not NLS_DEFAULT. And FAT_DEFAULT_CODEPAGE
only recognizes the numbers.)

Previously, it recognized/loaded all NLS modules via CONFIG_NLS_DEFAULT,
if it can't load the nls_cp437.ko or specified codepage.

But this is seriously wrong. For example, if fatfs using the
nls_utf8.ko for codepage, it will store the wrong 8.3-alias to
disk. (At least, windows can't read this. And several peoples reported
this problem.)

Anyway, could you please check FAT_DEFAULT_CODE/FAT_DEFAULT_IOCHARSET
and NLS_xxx in your .config.

Yes, this should be done automatically by config system. However...
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

[BUG] FAT broken in 2.6.7-bk15

[Ali Akcaagac]

Hello,

The recent changes in 2.6.7-bk15 broke FAT support. I am doing some
rescue backup systems here using tools like syslinux and mtools to
format a normal msdos disk (for el-torito). I figured out that after
creating and formating of these disks that it is impossible to mount
them with 'msdos' or 'vfat'. Even recompiling mtools with current
changes show the same issues. Please someone check up and fix the issues
(maybe reverting the changes).

PS: I am not subscribed to this list so in case you need to CC: me.

Re: [BUG] FAT broken in 2.6.7-bk15

[Andries Brouwer]

On Sun, Jul 04, 2004 at 01:28:28PM +0200, Ali Akcaagac wrote:

> The recent changes in 2.6.7-bk15 broke FAT support. I am doing some
> rescue backup systems here using tools like syslinux and mtools to
> format a normal msdos disk (for el-torito). I figured out that after
> creating and formating of these disks that it is impossible to mount
> them with 'msdos' or 'vfat'.

You may be able to check for yourself precisely which change caused
trouble for you. The only very recent change is one that makes the
kernel more permissive.

Give details on what versions work for you, what versions don't.
Give the exact error messages. Give the first few sectors of the
filesystem that you cannot mount but can mount with an earlier kernel.

Andries

Re: [BUG] FAT broken in 2.6.7-bk15

[Jesse Stockall]

On Sun, 2004-07-04 at 07:28, Ali Akcaagac wrote:
> Hello,
> 
> The recent changes in 2.6.7-bk15 broke FAT support. I am doing some
> rescue backup systems here using tools like syslinux and mtools to
> format a normal msdos disk (for el-torito). I figured out that after
> creating and formating of these disks that it is impossible to mount
> them with 'msdos' or 'vfat'. Even recompiling mtools with current
> changes show the same issues. Please someone check up and fix the issues
> (maybe reverting the changes).

Check syslog for error messages, I had a similar problem due to the
codepage module not being loaded. Sometime after 2.6.7 there were config
changes for FAT default codepage.

Jesse

-- 
Jesse Stockall <stockall@magma.ca>