diff mbox

hfsplus: fix the bug that cannot recognize files with hangul file name

Message ID 1510906805-2142-1-git-send-email-tchou@synology.com (mailing list archive)
State New, archived
Headers show

Commit Message

tchou Nov. 17, 2017, 8:20 a.m. UTC
The unicode of hangul from macOS is decomposed. There has a bug that
mistake decomposed unicode for composed when change unicode to ascii,
so it cannot recognize the hangul correctly.

Signed-off-by: Ting-Chang Hou <tchou@synology.com>
---
 fs/hfsplus/unicode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Ernesto A. Fernández Nov. 19, 2017, 12:57 a.m. UTC | #1
On Fri, Nov 17, 2017 at 04:20:05PM +0800, Ting-Chang Hou wrote:
> The unicode of hangul from macOS is decomposed. There has a bug that
> mistake decomposed unicode for composed when change unicode to ascii,
> so it cannot recognize the hangul correctly.
> 
> Signed-off-by: Ting-Chang Hou <tchou@synology.com>
> ---
>  fs/hfsplus/unicode.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/hfsplus/unicode.c b/fs/hfsplus/unicode.c
> index dfa90c2..2daf7b0 100644
> --- a/fs/hfsplus/unicode.c
> +++ b/fs/hfsplus/unicode.c
> @@ -135,7 +135,7 @@ int hfsplus_uni2asc(struct super_block *sb,
>  	ustrlen = be16_to_cpu(ustr->length);
>  	len = *len_p;
>  	ce1 = NULL;
> -	compose = !test_bit(HFSPLUS_SB_NODECOMPOSE, &HFSPLUS_SB(sb)->flags);
> +	compose = test_bit(HFSPLUS_SB_NODECOMPOSE, &HFSPLUS_SB(sb)->flags);

I'm not sure this is a mistake. The developers probably wanted the
filenames to be recomposed before being presented in utf8. With your patch,
if you try the following (with the default mount options):

  touch Á
  ls | hexdump -C

the utf8 output filename will be using the combining accent (CC 81) instead
of the Á character (C3 81). This is a bit annoying because it won't print
correctly in my terminal anymore.

What is it exactly that you are trying to fix? You mention an issue with
hangul characters, but I failed to trigger it. Could you expand on that?

>  	while (ustrlen > 0) {
>  		c0 = be16_to_cpu(*ip++);
> -- 
> 2.7.4
>
tchou Nov. 23, 2017, 3:57 a.m. UTC | #2
> Could you please share the examples of incorrect and correct
> behaviour?

> What is it exactly that you are trying to fix? You mention an issue 
> with
> hangul characters, but I failed to trigger it. Could you expand on 
> that?
> 

Hi all,
There is an example.I use Mac mini to format my usb disk to HFS+ and 
touch
the file with filename "공유"(a Korean actor, https://goo.gl/VcBsrn) on 
it.
After it, I mount the usb disk on my ubuntu(Linux 4.14.0+) and get the
following error message when trying to ls and cp the file:

ls: cannot access 공유: No such file or directory
cp: cannot stat ‘공유’: No such file or directory

It seem's a problem for a long time(https://goo.gl/LiWGe5).
After applying my patch, I can ls and cp the file correctly.

> On Fri, Nov 17, 2017 at 04:20:05PM +0800, Ting-Chang Hou wrote:
>> The unicode of hangul from macOS is decomposed. There has a bug that
>> mistake decomposed unicode for composed when change unicode to ascii,
>> so it cannot recognize the hangul correctly.
>> 
>> Signed-off-by: Ting-Chang Hou <tchou@synology.com>
>> ---
>>  fs/hfsplus/unicode.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/fs/hfsplus/unicode.c b/fs/hfsplus/unicode.c
>> index dfa90c2..2daf7b0 100644
>> --- a/fs/hfsplus/unicode.c
>> +++ b/fs/hfsplus/unicode.c
>> @@ -135,7 +135,7 @@ int hfsplus_uni2asc(struct super_block *sb,
>>  	ustrlen = be16_to_cpu(ustr->length);
>>  	len = *len_p;
>>  	ce1 = NULL;
>> -	compose = !test_bit(HFSPLUS_SB_NODECOMPOSE, &HFSPLUS_SB(sb)->flags);
>> +	compose = test_bit(HFSPLUS_SB_NODECOMPOSE, &HFSPLUS_SB(sb)->flags);
> 
> I'm not sure this is a mistake. The developers probably wanted the
> filenames to be recomposed before being presented in utf8. With your 
> patch,
> if you try the following (with the default mount options):
> 
>   touch Á
>   ls | hexdump -C
> 
> the utf8 output filename will be using the combining accent (CC 81) 
> instead
> of the Á character (C3 81). This is a bit annoying because it won't 
> print
> correctly in my terminal anymore.

I'm not exatly know why combining accent cannot print correctly in 
terminal
and how to avoid it. Whether apply my patch or not, my terminal cannot
print the hangul charactor correctly.
Viacheslav Dubeyko Nov. 23, 2017, 4:21 a.m. UTC | #3
On Thu, 2017-11-23 at 11:57 +0800, tchou wrote:
> > 
> > Could you please share the examples of incorrect and correct
> > behaviour?
> > 
> > What is it exactly that you are trying to fix? You mention an
> > issue 
> > with
> > hangul characters, but I failed to trigger it. Could you expand on 
> > that?
> > 
> Hi all,
> There is an example.I use Mac mini to format my usb disk to HFS+ and 
> touch
> the file with filename "공유"(a Korean actor, https://goo.gl/VcBsrn)
> on 
> it.
> After it, I mount the usb disk on my ubuntu(Linux 4.14.0+) and get
> the
> following error message when trying to ls and cp the file:
> 


Could you share the all mount options that you used? It looks that you
simply don't use the proper mount options set under the Linux. Because
MacOS X will mount properly always.

Thanks,
Vyacheslav Dubeyko.



> ls: cannot access 공유: No such file or directory
> cp: cannot stat ‘공유’: No such file or directory
> 
> It seem's a problem for a long time(https://goo.gl/LiWGe5).
> After applying my patch, I can ls and cp the file correctly.
> 
> > 
> > On Fri, Nov 17, 2017 at 04:20:05PM +0800, Ting-Chang Hou wrote:
> > > 
> > > The unicode of hangul from macOS is decomposed. There has a bug
> > > that
> > > mistake decomposed unicode for composed when change unicode to
> > > ascii,
> > > so it cannot recognize the hangul correctly.
> > > 
> > > Signed-off-by: Ting-Chang Hou <tchou@synology.com>
> > > ---
> > >  fs/hfsplus/unicode.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/fs/hfsplus/unicode.c b/fs/hfsplus/unicode.c
> > > index dfa90c2..2daf7b0 100644
> > > --- a/fs/hfsplus/unicode.c
> > > +++ b/fs/hfsplus/unicode.c
> > > @@ -135,7 +135,7 @@ int hfsplus_uni2asc(struct super_block *sb,
> > >  	ustrlen = be16_to_cpu(ustr->length);
> > >  	len = *len_p;
> > >  	ce1 = NULL;
> > > -	compose = !test_bit(HFSPLUS_SB_NODECOMPOSE,
> > > &HFSPLUS_SB(sb)->flags);
> > > +	compose = test_bit(HFSPLUS_SB_NODECOMPOSE,
> > > &HFSPLUS_SB(sb)->flags);
> > I'm not sure this is a mistake. The developers probably wanted the
> > filenames to be recomposed before being presented in utf8. With
> > your 
> > patch,
> > if you try the following (with the default mount options):
> > 
> >   touch Á
> >   ls | hexdump -C
> > 
> > the utf8 output filename will be using the combining accent (CC
> > 81) 
> > instead
> > of the Á character (C3 81). This is a bit annoying because it
> > won't 
> > print
> > correctly in my terminal anymore.
> I'm not exatly know why combining accent cannot print correctly in 
> terminal
> and how to avoid it. Whether apply my patch or not, my terminal
> cannot
> print the hangul charactor correctly.
> 
>
tchou Nov. 23, 2017, 6:05 a.m. UTC | #4
Viacheslav Dubeyko 於 2017-11-23 12:21 寫到:
> On Thu, 2017-11-23 at 11:57 +0800, tchou wrote:
>> >
>> > Could you please share the examples of incorrect and correct
>> > behaviour?
>> >
>> > What is it exactly that you are trying to fix? You mention an
>> > issue 
>> > with
>> > hangul characters, but I failed to trigger it. Could you expand on 
>> > that?
>> >
>> Hi all,
>> There is an example.I use Mac mini to format my usb disk to HFS+ and 
>> touch
>> the file with filename "공유"(a Korean actor, https://goo.gl/VcBsrn)
>> on 
>> it.
>> After it, I mount the usb disk on my ubuntu(Linux 4.14.0+) and get
>> the
>> following error message when trying to ls and cp the file:
>> 
> 
> 
> Could you share the all mount options that you used? It looks that you
> simply don't use the proper mount options set under the Linux. Because
> MacOS X will mount properly always.
> 
> Thanks,
> Vyacheslav Dubeyko.
> 
Hi Vyacheslav,

I use the default mount option:

mount /dev/sdc1 /mnt/hfs
/dev/sdc1 on /mnt/hfs type hfsplus 
(rw,relatime,umask=22,uid=0,gid=0,nls=utf8)

Thanks,
TCHou
> 
> 
>> ls: cannot access 공유: No such file or directory
>> cp: cannot stat ‘공유’: No such file or directory
>> 
>> It seem's a problem for a long time(https://goo.gl/LiWGe5).
>> After applying my patch, I can ls and cp the file correctly.
>> 
>> >
>> > On Fri, Nov 17, 2017 at 04:20:05PM +0800, Ting-Chang Hou wrote:
>> > >
>> > > The unicode of hangul from macOS is decomposed. There has a bug
>> > > that
>> > > mistake decomposed unicode for composed when change unicode to
>> > > ascii,
>> > > so it cannot recognize the hangul correctly.
>> > >
>> > > Signed-off-by: Ting-Chang Hou <tchou@synology.com>
>> > > ---
>> > >  fs/hfsplus/unicode.c | 2 +-
>> > >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > >
>> > > diff --git a/fs/hfsplus/unicode.c b/fs/hfsplus/unicode.c
>> > > index dfa90c2..2daf7b0 100644
>> > > --- a/fs/hfsplus/unicode.c
>> > > +++ b/fs/hfsplus/unicode.c
>> > > @@ -135,7 +135,7 @@ int hfsplus_uni2asc(struct super_block *sb,
>> > >  	ustrlen = be16_to_cpu(ustr->length);
>> > >  	len = *len_p;
>> > >  	ce1 = NULL;
>> > > -	compose = !test_bit(HFSPLUS_SB_NODECOMPOSE,
>> > > &HFSPLUS_SB(sb)->flags);
>> > > +	compose = test_bit(HFSPLUS_SB_NODECOMPOSE,
>> > > &HFSPLUS_SB(sb)->flags);
>> > I'm not sure this is a mistake. The developers probably wanted the
>> > filenames to be recomposed before being presented in utf8. With
>> > your 
>> > patch,
>> > if you try the following (with the default mount options):
>> >
>> >   touch Á
>> >   ls | hexdump -C
>> >
>> > the utf8 output filename will be using the combining accent (CC
>> > 81) 
>> > instead
>> > of the Á character (C3 81). This is a bit annoying because it
>> > won't 
>> > print
>> > correctly in my terminal anymore.
>> I'm not exatly know why combining accent cannot print correctly in 
>> terminal
>> and how to avoid it. Whether apply my patch or not, my terminal
>> cannot
>> print the hangul charactor correctly.
>> 
>>
Viacheslav Dubeyko Nov. 23, 2017, 6:23 a.m. UTC | #5
On Thu, 2017-11-23 at 14:05 +0800, tchou wrote:
> Viacheslav Dubeyko 於 2017-11-23 12:21 寫到:
> > 
> > On Thu, 2017-11-23 at 11:57 +0800, tchou wrote:
> > > 
> > > > 
> > > > 
> > > > Could you please share the examples of incorrect and correct
> > > > behaviour?
> > > > 
> > > > What is it exactly that you are trying to fix? You mention an
> > > > issue 
> > > > with
> > > > hangul characters, but I failed to trigger it. Could you expand
> > > > on 
> > > > that?
> > > > 
> > > Hi all,
> > > There is an example.I use Mac mini to format my usb disk to HFS+
> > > and 
> > > touch
> > > the file with filename "공유"(a Korean actor, https://goo.gl/VcBsrn
> > > )
> > > on 
> > > it.
> > > After it, I mount the usb disk on my ubuntu(Linux 4.14.0+) and
> > > get
> > > the
> > > following error message when trying to ls and cp the file:
> > > 
> > 
> > Could you share the all mount options that you used? It looks that
> > you
> > simply don't use the proper mount options set under the Linux.
> > Because
> > MacOS X will mount properly always.
> > 
> > Thanks,
> > Vyacheslav Dubeyko.
> > 
> Hi Vyacheslav,
> 
> I use the default mount option:
> 
> mount /dev/sdc1 /mnt/hfs
> /dev/sdc1 on /mnt/hfs type hfsplus 
> (rw,relatime,umask=22,uid=0,gid=0,nls=utf8)
> 


Please, take a look into mount options description [1]. Especially,
take a look into decompose/nodecompose options. You simply needs to use
the proper mount option for your case.

Thanks,
Vyacheslav Dubeyko.


[1] https://www.kernel.org/doc/Documentation/filesystems/hfsplus.txt

> Thanks,
> TCHou
> >
tchou Nov. 23, 2017, 6:34 a.m. UTC | #6
Viacheslav Dubeyko 於 2017-11-23 14:23 寫到:
> On Thu, 2017-11-23 at 14:05 +0800, tchou wrote:
>> Viacheslav Dubeyko 於 2017-11-23 12:21 寫到:
>> >
>> > On Thu, 2017-11-23 at 11:57 +0800, tchou wrote:
>> > >
>> > > >
>> > > >
>> > > > Could you please share the examples of incorrect and correct
>> > > > behaviour?
>> > > >
>> > > > What is it exactly that you are trying to fix? You mention an
>> > > > issue 
>> > > > with
>> > > > hangul characters, but I failed to trigger it. Could you expand
>> > > > on 
>> > > > that?
>> > > >
>> > > Hi all,
>> > > There is an example.I use Mac mini to format my usb disk to HFS+
>> > > and 
>> > > touch
>> > > the file with filename "공유"(a Korean actor, https://goo.gl/VcBsrn
>> > > )
>> > > on 
>> > > it.
>> > > After it, I mount the usb disk on my ubuntu(Linux 4.14.0+) and
>> > > get
>> > > the
>> > > following error message when trying to ls and cp the file:
>> > >
>> >
>> > Could you share the all mount options that you used? It looks that
>> > you
>> > simply don't use the proper mount options set under the Linux.
>> > Because
>> > MacOS X will mount properly always.
>> >
>> > Thanks,
>> > Vyacheslav Dubeyko.
>> >
>> Hi Vyacheslav,
>> 
>> I use the default mount option:
>> 
>> mount /dev/sdc1 /mnt/hfs
>> /dev/sdc1 on /mnt/hfs type hfsplus 
>> (rw,relatime,umask=22,uid=0,gid=0,nls=utf8)
>> 
> 
> 
> Please, take a look into mount options description [1]. Especially,
> take a look into decompose/nodecompose options. You simply needs to use
> the proper mount option for your case.
> 
I got it. It's my mistake.
Thank you all for making me right.

Thanks,
TCHou

> Thanks,
> Vyacheslav Dubeyko.
> 
> 
> [1] https://www.kernel.org/doc/Documentation/filesystems/hfsplus.txt
> 
>> Thanks,
>> TCHou
>> >
diff mbox

Patch

diff --git a/fs/hfsplus/unicode.c b/fs/hfsplus/unicode.c
index dfa90c2..2daf7b0 100644
--- a/fs/hfsplus/unicode.c
+++ b/fs/hfsplus/unicode.c
@@ -135,7 +135,7 @@  int hfsplus_uni2asc(struct super_block *sb,
 	ustrlen = be16_to_cpu(ustr->length);
 	len = *len_p;
 	ce1 = NULL;
-	compose = !test_bit(HFSPLUS_SB_NODECOMPOSE, &HFSPLUS_SB(sb)->flags);
+	compose = test_bit(HFSPLUS_SB_NODECOMPOSE, &HFSPLUS_SB(sb)->flags);
 
 	while (ustrlen > 0) {
 		c0 = be16_to_cpu(*ip++);