Linux - Ubuntu Karmic 64bit, 2.6.31-19-generic
Mac OS - Mac OS X Snow Leopard 10.6.2 32bit.
Steps to reprocude
1. Prepare HFS+ filesystem.
- Be sure the HFS+ fs does not have journaling.
- It is not important whether the HFS+ fs is made on Linux or Mac OS.
- It is not important whether the HFS+ fs is case-sensitive or case-insensitive.
2. Make any Korean-named file in HFS+ fs on Linux.
- For example, run "touch '한'" on terminal.
- '한' is D55C in Unicode.
3. Run 'ls' on Mac OS.
4. You will see error "ls: cannot access 한: No such file or directory".
* If you make any Korean-named file in HFS+ fs on Mac OS and run 'ls' on Linux, you will same error.
* I tested for some umlaut characters. But I could not see any error.
I know that HFS+ stores file name with decomposed Unicode form. I wanted to see whether file name was really decomposed or not. So I used hfsdebug-lite on Mac OS. It is debugger for HFS+. It shows real unicode value of the file name. You can find it from http://osxbook.com/software/hfsdebug/man.html.
For the file '한' made on Linux, hfsdebug-lite shows %D55C. And for the file '한' made on Mac OS, hfsdebug-lite shows %1112%1161%11AB.
'한' is composed with 3 syllabics - 'ㅎ', 'ㅏ' and 'ㄴ'. 'ㅎ' is 1112 in Unicode. 'ㅏ' is 1161. And 'ㄴ' is 11AB. Therefore, file name '한' should be presented with %1112%1161%11AB on HFS+ fs. Because it is dec
But for the file name which consists of umlaute characters, they are decomposed properly regardless that
they are made on Linux or Mac OS.
Maybe Linux kernel stores Korean file name as precomposed form for HFS+ fs. I think it should be fixed.
Does anybody know this problem?