vfat filesystem: Why utf8=1 when iocharset=”utf8” was already there?

vfat filesystem: Why utf8=1 when iocharset=”utf8” was already there?

[Amit Sahrawat]

>From my opinion both should support the same functionality as the
motive behind this seems to introduce the complete support for utf8.
But, I am surprised to see the behavior changes in the ‘2’ options.
1)	When using iocharset=”utf8” it makes vfat case sensitive, while
this is not the case with using utf8=1
2)	Surrogate pair don’t work when using iocharset=”utf8”, because that
traverses a path like this:
xlate_to_uni()-->nls->char2uni()-->char2uni()-->utf8_to_utf32()
After this it returns EINVAL because Surrogate pair correct code is
greater than 0xFFFF (MAX_WCHAR_T – limit which is put)
But this is not the case with utf8=1
There are other places also where I can see usage different due to
usage of char2uni()

Can someone provide any help on this? Why do we have separate options
for using utf8 and if utf8=1 smoothly supports proper working then why
not discard iocharset=”utf8” ? and if this is not the case
why was utf8=1 introduced?

Please provide any guidance in this.

Thanks & Regards,
Amit Sahrawat

Re: vfat filesystem: Why utf8=1 when iocharset=”utf8” was already there?

[NamJae Jeon]

2011/9/2 Amit Sahrawat <amit.sahrawat83@gmail.com>:
> From my opinion both should support the same functionality as the
> motive behind this seems to introduce the complete support for utf8.
> But, I am surprised to see the behavior changes in the ‘2’ options.
> 1)      When using iocharset=”utf8” it makes vfat case sensitive, while
> this is not the case with using utf8=1
> 2)      Surrogate pair don’t work when using iocharset=”utf8”, because that
> traverses a path like this:
> xlate_to_uni()-->nls->char2uni()-->char2uni()-->utf8_to_utf32()
> After this it returns EINVAL because Surrogate pair correct code is
> greater than 0xFFFF (MAX_WCHAR_T – limit which is put)
> But this is not the case with utf8=1
> There are other places also where I can see usage different due to
> usage of char2uni()
>
> Can someone provide any help on this? Why do we have separate options
> for using utf8 and if utf8=1 smoothly supports proper working then why
> not discard iocharset=”utf8” ? and if this is not the case
> why was utf8=1 introduced?
>
> Please provide any guidance in this.
>
> Thanks & Regards,
> Amit Sahrawat
>

I also am wondering this issue for long time.
May be, Ogawa will know well.

Re: vfat filesystem: Why utf8=1 when iocharset=”utf8” was already there?

[NamJae Jeon]

2011/9/3 OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>:
> NamJae Jeon <linkinjeon@gmail.com> writes:
>
>> 2011/9/2 Amit Sahrawat <amit.sahrawat83@gmail.com>:
>>> From my opinion both should support the same functionality as the
>>> motive behind this seems to introduce the complete support for utf8.
>>> But, I am surprised to see the behavior changes in the ‘2’ options.
>>> 1)      When using iocharset=”utf8” it makes vfat case sensitive, while
>>> this is not the case with using utf8=1
>>> 2)      Surrogate pair don’t work when using iocharset=”utf8”, because that
>>> traverses a path like this:
>>> xlate_to_uni()-->nls->char2uni()-->char2uni()-->utf8_to_utf32()
>>> After this it returns EINVAL because Surrogate pair correct code is
>>> greater than 0xFFFF (MAX_WCHAR_T – limit which is put)
>>> But this is not the case with utf8=1
>>> There are other places also where I can see usage different due to
>>> usage of char2uni()
>>>
>>> Can someone provide any help on this? Why do we have separate options
>>> for using utf8 and if utf8=1 smoothly supports proper working then why
>>> not discard iocharset=”utf8” ? and if this is not the case
>>> why was utf8=1 introduced?
>>>
>>> Please provide any guidance in this.
>>>
>>> Thanks & Regards,
>>> Amit Sahrawat
>>>
>>
>> I also am wondering this issue for long time.
>> May be, Ogawa will know well.
>
> History is simple. There already was the utf8 option before nls utf8
> module was introduced. And utf8 was introduced for other of FAT.
>
> Well, it doesn't provide case letter conversion table for some
> reasons. But, FAT requires conversion table. For utf8 option, it
> emulates the case conversion by using tables in iocharset= or nls= nls
> module.
>
> NLS infrastructure has several limitation, and to support encoding
> conversion and case letter more fully, it would be better to introduce
> new infrastructure. But it would need not small change.
>
> Thanks.
> --
> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
>

Hi. Ogawa.

If the user to use FAT first time, they are confused about this
option, or they may use only iocharset without knowing the utf8
option(there is case sensitive issue). If nls_utf8 is improved such as
adding upper/lower case translation table, supporting surrogate pair
etc.., I want to know whether you can integate only iocharset=utf8
with removing utf8 option.
If done like above my suggetion, user can use only
option(iocharset=utf8) without confusing.

Thanks.

Re: vfat filesystem: Why utf8=1 when iocharset=”utf8” was already there?

[NamJae Jeon]

2011/9/5 OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>:
> NamJae Jeon <linkinjeon@gmail.com> writes:
>
>> I want to know whether you can integate only iocharset=utf8 with
>> removing utf8 option.
>
> I guess *I* will not do, because I don't have time (and maybe
> motivation) to concentrate it.
>
> Furthermore, even if I had time, I think I will not use current options
> anymore. Instead, I will add new infrastructure like we can support more
> flexible (like kiconv? on freebsd). And I suppose the both
> infrastructures (and options) will be used until it is completely
> migrated.
>
> Thanks.
> --
> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
>
Thanks for your reply.
I have a question. Do you know who is nls maintainer ?
I can not find it in MAINTAINERS file.

Thanks.