Leon> This is good comparison. Maybe a better comparison is to make a
Leon> same filename like 日本語 on linux, dump the FAT table and
Leon> delete it, and then make same filename in Windows, dump the FAT
Leon> table and compare those two data.
Tried this. Now the data are the same, and linux-2.4.18 chokes on
both. It will not return UTF strings for the filenames. I just get
this:
# ls -l /tmp/cf
-rwxr-xr-x 1 root 0 42 Sep 10 12:42 ______~1
-rwxr-xr-x 1 root 0 27 Sep 10 12:44 ____~1
-rwxr-xr-x 1 root 0 27 Sep 10 12:44 ____~2
-rwxr-xr-x 1 root 0 33 Sep 10 12:43 ___ats~1
-rwxr-xr-x 1 root 0 24 Sep 10 12:41 ___~1
-rwxr-xr-x 1 root 0 20 Sep 10 12:40 ascii
-rwxr-xr-x 1 root 0 24 Sep 10 12:41 ascii-~1
-rwxr-xr-x 1 root 0 31 Sep 10 12:43 atend_~1
-rwxr-xr-x 1 root 0 34 Sep 10 12:43 in___m~1
#
When I mount this same CF on a laptop running linux-2.6.5, I get this:
# ls -l flash
total 18
total 18
-rwxr-xr-x 1 root root 27 Sep 10 03:44 カタカナ
-rwxr-xr-x 1 root root 27 Sep 10 03:44 ひらがな
-rwxr-xr-x 1 root root 20 Sep 10 03:40 ascii
-rwxr-xr-x 1 root root 24 Sep 10 03:41 ascii-long-name
-rwxr-xr-x 1 root root 31 Sep 10 03:43 atend日本語
-rwxr-xr-x 1 root root 34 Sep 10 03:43 in日本語middle
-rwxr-xr-x 1 root root 24 Sep 10 03:41 日本語
-rwxr-xr-x 1 root root 33 Sep 10 03:43 日本語atstart
-rwxr-xr-x 1 root root 42 Sep 10 03:42 日本語とても長いファイル名
#
I thought that it might be the ls program that has the problem, but
when I strace the ls, it looks like the characters are already bogus
in the glibc layer:
open("/tmp/cf", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=16384, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
getdents64(3, /* 11 entries */, 2048) = 336
lstat64("/tmp/cf/ascii", {st_mode=S_IFREG|0755, st_size=20, ...}) = 0
lstat64("/tmp/cf/ascii-~1", {st_mode=S_IFREG|0755, st_size=24, ...}) = 0
lstat64("/tmp/cf/___~1", {st_mode=S_IFREG|0755, st_size=24, ...}) = 0
lstat64("/tmp/cf/______~1", {st_mode=S_IFREG|0755, st_size=42, ...}) = 0
lstat64("/tmp/cf/___ats~1", {st_mode=S_IFREG|0755, st_size=33, ...}) = 0
lstat64("/tmp/cf/in___m~1", {st_mode=S_IFREG|0755, st_size=34, ...}) = 0
lstat64("/tmp/cf/atend_~1", {st_mode=S_IFREG|0755, st_size=31, ...}) = 0
lstat64("/tmp/cf/____~1", {st_mode=S_IFREG|0755, st_size=27, ...}) = 0
lstat64("/tmp/cf/____~2", {st_mode=S_IFREG|0755, st_size=27, ...}) = 0
getdents64(3, /* 0 entries */, 2048) = 0
close(3) = 0
My guess is that the getdents64() system call is returning the wrong
values, but I can't tell. This is the same regardless of what
codepage or iocharset I specify:
# mount linux-cf-test.img /tmp/cf -t msdos -o loop,codepage=437
# ls /tmp/cf
______~1 ____~2 ___~1 ascii-~1 in___m~1
____~1 ___ats~1 ascii atend_~1
# umount /tmp/cf
# mount linux-cf-test.img /tmp/cf -t msdos -o loop,codepage=932
# ls /tmp/cf
______~1 ____~2 ___~1 ascii-~1 in___m~1
____~1 ___ats~1 ascii atend_~1
# umount /tmp/cf
# mount linux-cf-test.img /tmp/cf -t msdos -o loop,codepage=932,iocharset=utf8
# ls /tmp/cf
______~1 ____~2 ___~1 ascii-~1 in___m~1
____~1 ___ats~1 ascii atend_~1
# mount
/dev/root on / type nfs (rw,v2,rsize=1024,wsize=1024,hard,udp,nolock,addr=192.168.5.1)
none on /dev type devfs (rw)
/proc on /proc type proc (rw)
tmpfs on /tmp type tmpfs (rw)
tmpfs on /var type tmpfs (rw)
tmpfs on /mnt/smb type tmpfs (rw)
/dev/ide/host0/bus0/target0/lun0/part1 on /mnt/flash1 type vfat (ro,noatime)
/dev/loop/0 on /tmp/cf type msdos (rw)
#
Any suggestions on how to debug this?
Thanks,
Dave
