Hello everyone,
this is one of those things that you think you have got completely over yet once in a while something just does not work as you expect it.

So I have an old microSD card (vfat filesystem) from my android phone and I wanted to migrate the data to a larger microSD card. Note that connecting the card to an ubuntu system shows correctly all the filenames - english and greek alike, in CLI.

Now inserting the same microSD card in my slackware system will show (in CLI always) the greek characters in filenames replaced with question marks. No the slackware system is a headless server, so I ssh into it.

Also, I have not altered the /etc/profile.d/lang.sh or ~/.profile files and unless you state otherwise I would prefer to keep it that way(they are default "en_US"). so for the bash session I
the filename still has question marks:
no fear, I thought the font is not correct so I loaded many greek fonts in turn from , which unfortunately did not solve the problem even though the fonts loaded up fine. for example:
I checked that unicode is enabled with "kbd_mode"
(note: by choosing el_GR.UTF-8 and redoing this test I will successfully see the above message translated in greek, but the filenames will still appear as question marks)

Also, "stty -a" has the -iutf8 flag (as the slack docs suggest to check).

I have read alot of related information on the internet including:
http://docs.slackware.com/slackware:localization
http://www.linuxquestions.org/questi...nguage-713154/
http://members.hellug.gr/djart/artic...x/grlinux.html
several greek sites

I honestly do not know what else to try to show these characters correctly from ssh session. Note that all the above where run as root so there should not be any permission issues. What am I missing here?

thank you in advance for your help!

Wonder if something else is going on and not just name issue.

So from linux it works correctly??

Just copy off data then and move over may be that way and seem if new drive also acts the same?

Not sure what you mean.


Copying the data and seeing everything on a more unix oriented partition did not solve the problem. still question marks...

Another area to investigate may be how the card is mounted. Perhaps something funny is going on with how the card is mounted as a filesystem.

The first question is: is it a legacy OEM encoding (1 byte per character) or a multi-byte one (Unicode, UTF-8 or UTF-16). This page says the former for FAT12, FAT16, and FAT32 , but the man page for convmv says that internally FAT16 is used. A way to check would be to check the number of bytes used to display the filename.

Anyhow see convmv.

Maybe ssh to the box from an uXterm
to be sure the terminal works with Unicode Characters.

And also try to mount the SD card with the option iocharset=utf8

Enjoy

1 members found this post helpful.

Mount the SD card using a UTF-8 encoding as mounting options.
Since the card originated from an Android device, the filenames were originally written using this encoding.
Failing that, try mounting the card using the ISO-8859-7 encoding.
No reason to mess with fonts or terminal settings.

from my notes:

Mount fat32 external hdd with utf8 ( for correct display russian and so on filenames) in linux ( in default mount with ancient western codepage !!!):

mount -t vfat -o defaults,utf8 /dev/sdd1 /mnt/tmp

1 members found this post helpful.

Did you try to enable utf8 in lilo.conf:

append="vt.default_utf8=1"

http://www.slackwiki.com/Utf-8_linux_console

that seems to be vfat mounting problem - i defoult, "mount" command mount it with something ancient codepage, who causes all that problems.
Wondering, why novadays "mount" command not mount all media with utf8 cp?

may be good to make in slackdocs small "howto" about vfat and utf8 mount ? Anyone want to do this?

Ls itself doesn't display 8 bit characters in filenames until told so by setting LC_CTYPE and maybe using the option "-N". Look up locale(7) in the manual pages.

FAT itself (the on-disk format) doesn't support UTF-8 nor UTF-16. It only supports the preceding UCS-2 (used by Windows 95) for "long" filenames and IBM-DOS codepages for short filesnames.

1 members found this post helpful.