I wrote:
More details on what the patch does:
* Rewords the description of CONFIG_NLS_DEFAULT, because at some point
in the past it confused some people
* Removes CONFIG_FAT_DEFAULT_IOCHARSET, now CONFIG_NLS_DEFAULT is used
for this purpose. This is because the correct setting of both must
Hi,
On Thu, 22 Mar 2007, Alexander E. Patrakov wrote:
> > hfs has a codepage option as well, but I don't know its default in the
> > various countries, but it could be different from DOS.
>
> Yes. Since this comes from Mac world, it definitely makes sense to add
> CONFIG_MAC_CODEPAGE_DEFAULT,
Roman Zippel wrote:
hfs has a codepage option as well
Is it _currently_ useful at all? The problem is that the kernel has no nls
modules for Mac codepages (e.g., MacRoman which is cp1).
--
Alexander E. Patrakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Roman Zippel wrote:
hfs has a codepage option as well, but I don't know its default in the
various countries, but it could be different from DOS.
Yes. Since this comes from Mac world, it definitely makes sense to add
CONFIG_MAC_CODEPAGE_DEFAULT, the corresponding module parameter, and make
Hi,
On Thu, 22 Mar 2007, Alexander E. Patrakov wrote:
> It is exposed as a mount parameter and kernel configuration option only for
> fat and smbfs (the two filesystems that my patch touches for this matter), and
> both of these filesystems come from DOS days, where there was one codepage for
>
Roman Zippel wrote:
I agree that these parameters should be changable not just at compile time
and the iocharset should be a global default, but the on disk encoding is
often filesystem specific, so I'd rather keep this option per filesystem.
You are right, the on-disk encoding is filesystem
Hi,
On Sun, 18 Mar 2007, Alexander E. Patrakov wrote:
> More details on what the patch does:
>
> * Rewords the description of CONFIG_NLS_DEFAULT, because at some point in the
> past it confused some people
> * Removes CONFIG_FAT_DEFAULT_IOCHARSET, now CONFIG_NLS_DEFAULT is used for
> this
Hi,
On Sun, 18 Mar 2007, Alexander E. Patrakov wrote:
More details on what the patch does:
* Rewords the description of CONFIG_NLS_DEFAULT, because at some point in the
past it confused some people
* Removes CONFIG_FAT_DEFAULT_IOCHARSET, now CONFIG_NLS_DEFAULT is used for
this purpose.
Roman Zippel wrote:
I agree that these parameters should be changable not just at compile time
and the iocharset should be a global default, but the on disk encoding is
often filesystem specific, so I'd rather keep this option per filesystem.
You are right, the on-disk encoding is filesystem
Hi,
On Thu, 22 Mar 2007, Alexander E. Patrakov wrote:
It is exposed as a mount parameter and kernel configuration option only for
fat and smbfs (the two filesystems that my patch touches for this matter), and
both of these filesystems come from DOS days, where there was one codepage for
a
Roman Zippel wrote:
hfs has a codepage option as well, but I don't know its default in the
various countries, but it could be different from DOS.
Yes. Since this comes from Mac world, it definitely makes sense to add
CONFIG_MAC_CODEPAGE_DEFAULT, the corresponding module parameter, and make
Roman Zippel wrote:
hfs has a codepage option as well
Is it _currently_ useful at all? The problem is that the kernel has no nls
modules for Mac codepages (e.g., MacRoman which is cp1).
--
Alexander E. Patrakov
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Hi,
On Thu, 22 Mar 2007, Alexander E. Patrakov wrote:
hfs has a codepage option as well, but I don't know its default in the
various countries, but it could be different from DOS.
Yes. Since this comes from Mac world, it definitely makes sense to add
CONFIG_MAC_CODEPAGE_DEFAULT, the
I wrote:
More details on what the patch does:
* Rewords the description of CONFIG_NLS_DEFAULT, because at some point
in the past it confused some people
* Removes CONFIG_FAT_DEFAULT_IOCHARSET, now CONFIG_NLS_DEFAULT is used
for this purpose. This is because the correct setting of both must
"Alexander E. Patrakov" <[EMAIL PROTECTED]> writes:
> Would it be OK for you if I add the mount-time check for iocharset=utf8 to
> the fat filesystem and silently replace this with the "utf8" option, instead
> of overly actively warning the users? This way, the sysfs option and the
>
Alexander E. Patrakov [EMAIL PROTECTED] writes:
Would it be OK for you if I add the mount-time check for iocharset=utf8 to
the fat filesystem and silently replace this with the utf8 option, instead
of overly actively warning the users? This way, the sysfs option and the
nls_base.iocharset
OGAWA Hirofumi wrote:
"Alexander E. Patrakov" <[EMAIL PROTECTED]> writes:
But, anyway, this is a separate issue that my patch doesn't attempt to
correct. The conclusion so far is that we disagree, and that there are
situations where using utf8 iocharset is the least of all evils, so the
"Alexander E. Patrakov" <[EMAIL PROTECTED]> writes:
> Note that you can still achieve this insane result by specifying iocharset
> manually for each mount. Only the defaults are changed, but many distros set
> the default iocharset to either iso8859-1 or utf8, both of which are wrong
> for
"Alexander E. Patrakov" <[EMAIL PROTECTED]> writes:
> But, anyway, this is a separate issue that my patch doesn't attempt to
> correct. The conclusion so far is that we disagree, and that there are
> situations where using utf8 iocharset is the least of all evils, so the
> warning is not
OGAWA Hirofumi wrote:
I'm talking about two filesystems on a system here, not two encoding
on one filesystem. You can change locale on each filesystems, or each
directory, of course if it's not vfat.
Note that you can still achieve this insane result by specifying iocharset
manually for each
OGAWA Hirofumi wrote:
No, the utf8 support of vfat is wrong. This is implementation
thing, and it is not recommended until it is fixed.
Could you please explain your specific problem with screenshots, preferrably
by running my LiveCD or Debian Etch in an emulator such as qemu or VMware?
"Alexander E. Patrakov" <[EMAIL PROTECTED]> writes:
> OGAWA Hirofumi wrote:
>
>> I don't care about "read", because it doesn't corrupt filesystem. I care
>> about only "write", because it can corrupt filesystem.
>>
>> If it's read-only, I'll not care at all, and will agree.
>
> Here you are
Alexander E. Patrakov [EMAIL PROTECTED] writes:
OGAWA Hirofumi wrote:
I don't care about read, because it doesn't corrupt filesystem. I care
about only write, because it can corrupt filesystem.
If it's read-only, I'll not care at all, and will agree.
Here you are right, but please tell
OGAWA Hirofumi wrote:
No, the utf8 support of vfat is wrong. This is implementation
thing, and it is not recommended until it is fixed.
Could you please explain your specific problem with screenshots, preferrably
by running my LiveCD or Debian Etch in an emulator such as qemu or VMware?
OGAWA Hirofumi wrote:
I'm talking about two filesystems on a system here, not two encoding
on one filesystem. You can change locale on each filesystems, or each
directory, of course if it's not vfat.
Note that you can still achieve this insane result by specifying iocharset
manually for each
Alexander E. Patrakov [EMAIL PROTECTED] writes:
But, anyway, this is a separate issue that my patch doesn't attempt to
correct. The conclusion so far is that we disagree, and that there are
situations where using utf8 iocharset is the least of all evils, so the
warning is not justified
Alexander E. Patrakov [EMAIL PROTECTED] writes:
Note that you can still achieve this insane result by specifying iocharset
manually for each mount. Only the defaults are changed, but many distros set
the default iocharset to either iso8859-1 or utf8, both of which are wrong
for you. So you
OGAWA Hirofumi wrote:
Alexander E. Patrakov [EMAIL PROTECTED] writes:
But, anyway, this is a separate issue that my patch doesn't attempt to
correct. The conclusion so far is that we disagree, and that there are
situations where using utf8 iocharset is the least of all evils, so the
warning
OGAWA Hirofumi wrote:
I don't care about "read", because it doesn't corrupt filesystem. I care
about only "write", because it can corrupt filesystem.
If it's read-only, I'll not care at all, and will agree.
Here you are right, but please tell RedHat about this (and you'll be at
least called
"Alexander E. Patrakov" <[EMAIL PROTECTED]> writes:
> OGAWA Hirofumi wrote:
>> "Alexander E. Patrakov" <[EMAIL PROTECTED]> writes:
>>
You allow to set any nls to codepage? If so, it is not good.
>>> I did this because it involved less changes. Only FAT treats codepage as a
>>> number. All
OGAWA Hirofumi wrote:
"Alexander E. Patrakov" <[EMAIL PROTECTED]> writes:
You allow to set any nls to codepage? If so, it is not good.
I did this because it involved less changes. Only FAT treats codepage as a
number. All other filesystems already allow arbitrary NLS as a codepage
mount
"Alexander E. Patrakov" <[EMAIL PROTECTED]> writes:
>> You allow to set any nls to codepage? If so, it is not good.
>
> I did this because it involved less changes. Only FAT treats codepage as a
> number. All other filesystems already allow arbitrary NLS as a codepage
> mount parameter.
I'm
OGAWA Hirofumi wrote:
"Alexander E. Patrakov" <[EMAIL PROTECTED]> writes:
* Removes CONFIG_FAT_DEFAULT_IOCHARSET, now CONFIG_NLS_DEFAULT is used
for this purpose. This is because the correct setting of both must match
the user's locale
The some filesystems want to use utf-8, and others
"Alexander E. Patrakov" <[EMAIL PROTECTED]> writes:
> * Removes CONFIG_FAT_DEFAULT_IOCHARSET, now CONFIG_NLS_DEFAULT is used
> for this purpose. This is because the correct setting of both must match
> the user's locale
The some filesystems want to use utf-8, and others don't want to use
Alexander E. Patrakov [EMAIL PROTECTED] writes:
* Removes CONFIG_FAT_DEFAULT_IOCHARSET, now CONFIG_NLS_DEFAULT is used
for this purpose. This is because the correct setting of both must match
the user's locale
The some filesystems want to use utf-8, and others don't want to use
utf-8, no?
OGAWA Hirofumi wrote:
Alexander E. Patrakov [EMAIL PROTECTED] writes:
* Removes CONFIG_FAT_DEFAULT_IOCHARSET, now CONFIG_NLS_DEFAULT is used
for this purpose. This is because the correct setting of both must match
the user's locale
The some filesystems want to use utf-8, and others don't
Alexander E. Patrakov [EMAIL PROTECTED] writes:
You allow to set any nls to codepage? If so, it is not good.
I did this because it involved less changes. Only FAT treats codepage as a
number. All other filesystems already allow arbitrary NLS as a codepage
mount parameter.
I'm saying here,
OGAWA Hirofumi wrote:
Alexander E. Patrakov [EMAIL PROTECTED] writes:
You allow to set any nls to codepage? If so, it is not good.
I did this because it involved less changes. Only FAT treats codepage as a
number. All other filesystems already allow arbitrary NLS as a codepage
mount
Alexander E. Patrakov [EMAIL PROTECTED] writes:
OGAWA Hirofumi wrote:
Alexander E. Patrakov [EMAIL PROTECTED] writes:
You allow to set any nls to codepage? If so, it is not good.
I did this because it involved less changes. Only FAT treats codepage as a
number. All other filesystems
OGAWA Hirofumi wrote:
I don't care about read, because it doesn't corrupt filesystem. I care
about only write, because it can corrupt filesystem.
If it's read-only, I'll not care at all, and will agree.
Here you are right, but please tell RedHat about this (and you'll be at
least called an
40 matches
Mail list logo
