Codepage problem with NAS

[Andi B.]

I can connect to my sons NAS (guess it runs some sort of Linux) via FTP and SAMBA. But I've problems with special characters. Using netdrive ftp plugin I've to select 1208 UTF-8 which seems correct to me. Now I see a the character in picture CodepageProblem1.png correct.

But another character displays wrong see CodepageProblem3.png.

I can not set any codepage to display this on correct.

Wenn using netdrives samba plugin the first character displays correct. But the second character displays wrong too. I do not see any setting for samba to switch codepages. But samba shows this ´ different. See CodepageProblem2.png

Needless to say looking from Windoze to this samba share both special characters displays correct. See CodepageProblem4.png

Is our UTF-8 not the same as the Win and Linux one?

Another thing I noticed - using Seamonkey to connect to the NAS via ftp I can not find any codepage to display the second character, the ´, correct. Neither on eCS nor on Win. Seems to be a strange definition of ´ character which only Win can decode correct. Any hint to solve this?

[ivan]

Which NAS is it? 

What OS was used to write the files?

What do you see using just a plain FTP client - JFTP, NCFTP or NFTP for example?

I see the sort of things you are seeing in e-mails from my French friends that are using windows but I have never seen it with any of our 15 NAS boxes.

[Alex Taylor]

It's not the server codepage that determines how the characters are displayed, it's the local codepage. 

Assuming your system codepage is 850, the plugin has to translate the UTF-8 string into codepage 850 in order to display it. However, the typographic apostrophe (a.k.a. right single quote), which is evidently what is being used here, doesn't exist under codepage 850. Hence it's getting replaced by a substitution marker.

If you were to change your PM codepage to, say, 1004, I suspect the string would appear correctly.

[Andi B.]

Thanks Alex. I've read your excellent voice article about codepages now.

I've changed chcp to 850,1004 and played with cppal too but not much success. Different problems with VIO window and PM program LarsenCommander and difference between Samba and FTP.

Samba & LarsenCommander with 1004 - starting from a cmd shell after setting 'chcp 1004' leads to both of the above characters are displayed as blank. Changing font from WarpSans to Workplace Sans the apostrophe is displayed as rectangle. The 'a' in Grada with the skewed line above is displayed as blank with both fonts.

FTP & LarsenCommander with 1004 - WarpSans, Workplace Sans and SystemVIO displays characters correct now, hurray.

Samba & VIO - the strange 'a' with skewed line (what's the correct English term for this?) in 'Grada' is displayed correct only with chcp 850. Codepage 1004 seems to does not include this character and shows a blank. VIO with 1004 does not display the apostrophe too. VIO with 850 shows instead apostrophe the little house in CodepageProblem2 above. Beside that 1004 for VIO window is not good as it seems to miss the graphic symbols which are used to draw the frames in 4os2 popup windows. But FTP and VIO with cp1004 would display the two characters correct.

So still not satisfactory solution. Netdrive FTP and Samba (when used with LarsenCommander) gave different problems with different code pages. But I can not find a good setting for SAMBA.

Do I need a DBSC system? Or is this a problem with our Samba? Or is there a setting for Samba?

[ivan]

Hi Andi,

I asked the questions I did because I don't see what you are seeing with our D-Link NAS boxes.

Using standard code page 850 I see accented characters in the names of files stored on the NAS boxes even if they were placed there by a windows or linux OS (I am using our version of Samba and, where I need FTP, JFTP).  I use File Freedom as a file manager.

[Andi B.]

Sorry Ivan, forgot to answer your question. It's a self build NAS running Openmediavault which TTBOMK is based on Debian Linux.

The offending characters where saved there from a Windoze machine.

[Andi B.]

Okay another test with 'CODEPAGE=1004,850' in config.sys gave correct display with both SAMBA and FTP in LarsenCommander. But that breaks my desktop (Arbeitsoberfläche on German systems). Currently rebuilding my main machine from archive :-(

[ivan]

Hi Andy,

Since you built your NAS you should be able to check what codepage it is setup to use.  I know that several linux distributions are setup to be windows friendly which includes using the standard windows codepages - the fact that codepage 1004 shows the correct characters confirms this.

Changing the codepage of the NAS may solve your problem, on the other hand it might not.  If I get time tonight I will see about downloading openmediavault and see if we can find out what it uses to store file names.  I do have to say that I haven't seen any problems with accented characters, French, Spanish or German on our test machine that has OpenSUSE on it.

[Dave Yeo]

Samba & VIO - the strange 'a' with skewed line (what's the correct English term for this?)

I believe it's an acute accent. See https://en.wikipedia.org/wiki/Acute_accent which also shows the other diacritics.

[Andi B.]

Restore the backup is more hard as expected I have extracted the .zip while running cp1004 into a temporary directory. After switching back to cp850 I now can not even read that directory. Even plain cmd line booted from Alt-F1 is unable to read the root directory on the JFS temp partition. I can not even delete the directory from there.

Recreate from achive with ALT-F1 hangs for hours. Guess same problem while reading some directories/files.

Have to boot eCS boot CD to make some maintenance.

Which config.* is used for ALT-F1?

Plan is to change the codepage statement there to 850,1004, then boot with ALT-F1 cmd line, chcp 1004 and then delete the problematic directories/files.

[guzzi]

That's a known problem. When you write files with a certain codepage, then configure a different one, you're likely to end up with file names with illegal characters in them. Especially a hassle if you don't know which codepage was used to crate those files. In that case, only a format can get rid of them, or possibly correcting the file names with DFSEE in the JFS superblock.