14 December 2009, 19:18 | #1 |
Registered User
Join Date: Jul 2008
Location: Oslo
Posts: 76
|
Bug: Filenames containing national characters in Windows Directories
Not sure if this is reported before, so here goes.
Symptom: Certain national characters will give a "file not found" error in emmulated OS when used in filenames. Host system: Windows Vista Business SP2 Tested WinUAE versions -1.5.2 "kinda works" -1.6.1 "block" -2.0.0 "block" How to reproduce for 1.5.2:
How to reproduce for 1.6.1 and 2.0.0:
To see more examples, try copying all files from AmiKit AK0 under WinUAE 1.6.1+ and see which files that it reports errors on. I hope this is helpfull, and if there is any other way I can be of assistance, please do not hesitate to ask me for further help/debugging EDIT: I have tested the AmiKit.zip archive directly under WinUAE 1.5.2. The AmiKit.zip archive can be found here: http://amikit.amiga.sk/download/linu...nux-latest.zip Under 1.5.2 using the AmiKit.zip archive as a harddrive, the character bug is not present. Then it works just as it's supposed to. So it seems that the bug is "limited" to using directories on the host system. Last edited by arnljot; 14 December 2009 at 19:43. Reason: More testing |
15 December 2009, 12:21 | #2 |
Registered User
Join Date: Jul 2008
Location: Oslo
Posts: 76
|
Isn't there any one else who can confirm this bug?
|
15 December 2009, 12:35 | #3 |
HOL/FTP busy bee
Join Date: Sep 2006
Location: Germany
Age: 46
Posts: 32,000
|
Tested with German 'special' characters and it works both if created within WinUAE or on Windows. If I try your example, it creates "espan'ol" here and it still works.
|
15 December 2009, 12:47 | #4 | |
Registered User
Join Date: Jul 2008
Location: Oslo
Posts: 76
|
Quote:
Like I mention, it's certain filenames that gives issues. |
|
15 December 2009, 13:06 | #5 | |
HOL/FTP busy bee
Join Date: Sep 2006
Location: Germany
Age: 46
Posts: 32,000
|
Quote:
Edit : Extracting that folder from the Linux package with WinRAR result in 'espa±ol' as the directory name here. However, that name works then. Last edited by TCD; 15 December 2009 at 13:31. |
|
15 December 2009, 14:09 | #6 |
cheeky scoundrel
Join Date: Nov 2004
Location: Spijkenisse/Netherlands
Age: 42
Posts: 6,977
|
Linux filesystems default to UTF-8, while windoze filesystems use that weird microsoft encoding thingie (iso-8859-1, quick check). Might be the cause of the weird characters.
|
15 December 2009, 18:01 | #7 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,573
|
It only happens with very few specific national characters with specific Windows languages/regional setting. No, I can't duplicate this, it seems to be limited to some specific languages or something.. (I use english Windows)
Reason: for some weird reason "ansi" (iso-8859-1 and other non-unicode charsets) to unicode conversion converts some national characters to "plain" version. (or perhaps it was unicode to "ansi", don't remember), for example ñ becomes n. (even if destination charset does support both..) (btw, Windows internally uses UTF-16) This was originally reported by AmiKit author but as usual, I "can't" fix anything unless I can duplicate it myself.. Does anything change if you add "win32.filesystem_codepage=0" to configuration file? |
15 December 2009, 18:44 | #8 |
Registered User
Join Date: Jul 2008
Location: Oslo
Posts: 76
|
I absolutely understand that you can't fix something that you can't reproduce. Because you cannot create a test to verify that the fix is done.
I code too so this is 100% understandable. I'll try the codepage config and report back to you! :-) Thanks. |
15 December 2009, 19:03 | #9 |
Registered User
Join Date: Jul 2008
Location: Oslo
Posts: 76
|
|
15 December 2009, 19:15 | #10 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,573
|
|
15 December 2009, 19:28 | #11 |
Registered User
Join Date: Jul 2008
Location: Oslo
Posts: 76
|
I did.
Español works like it always has. Espanol with the accent(´) over the n doesn't work. I think this is a shortcomming in conversion routine like you mentioned working together with a bug in the extraction routine of the AmiKit installer. It's surely wrong that it's espańol and not Español. |
15 December 2009, 19:31 | #12 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,573
|
Problem is that those routines are Windows functions..
What Windows language version do you have? What do you have in "Currrent language for non-Unicode programs"? (Somewhere in control panel, regional settings) |
15 December 2009, 19:35 | #13 |
Registered User
Join Date: Jul 2008
Location: Oslo
Posts: 76
|
It's "Norsk, bokmål (Norge)".
That's norwegian. We have two variants of norwegian in Norway, this is the most common one. Should I try and set it to English? EDIT: fyi, changeing to british english didn't change it. Last edited by arnljot; 15 December 2009 at 19:45. |
15 December 2009, 20:21 | #14 |
The Spanish Songstress
Join Date: Jul 2009
Location: Finland
Posts: 114
|
Windows functions for character encodings are extremely sensitive to what language options you have set in the first place (and apps have to go "the extra mile" if they want to do anything about it).
If you try to show spanish text, it will get converted funnily if your locale settings are anything else but spanish (or a language with exactly the same accents). I.e., will not work ok in norwegian locale and neither in GB. Toni, is WUAE coded with full unicode support (the char_w version of functions etc and not ANSI set in project settings)? If not, this is not "fixable" easily without jumping through hoops in code (I've had to port a couple of apps for this only). |
16 December 2009, 18:10 | #15 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,573
|
Actually there are no problems. I think I confused this was another similar problem..
ń in espańol does not appear to be legal character in AmigaDOS (WB locale disk has only español) <1.6.0 does not show it because ń does not exists in iso-8859-1 and WinUAE can't access it. >=1.6.0 shows it because of unicode support but conversion to AmigaDOS path creates different name (ń becomes n because ń does not exist in Amiga charset) Perhaps >=1.6.0 should also hide files if they contain illegal characters.. |
16 December 2009, 18:32 | #16 | |
Registered User
Join Date: Jul 2008
Location: Oslo
Posts: 76
|
Quote:
I think it's a matter of taste... unfortunately. For AmiKit archive, it's gotta be correct then since WinUAE extracts it correctly. It's got to be the AmiKit installer which foobars it... |
|
17 December 2009, 01:02 | #17 |
Coder/webmaster/gamer
Join Date: Oct 2001
Location: Canberra/Australia
Posts: 2,678
|
I can confirm it, it's a longstanding bug.
|
17 December 2009, 12:19 | #18 |
Registered User
Join Date: Jul 2008
Location: Oslo
Posts: 76
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
WHDLoad games with Filenames not supported by Windows | killergorilla | project.Killergorilla's WHD packs | 18 | 20 November 2021 23:35 |
Unusual characters in filenames and shared folders | mark_k | support.WinUAE | 3 | 03 February 2013 19:50 |
Batman The Movie v1.4 betatest - MS Windows compatible filenames! | BoredSeal | project.WHDLoad | 15 | 04 August 2010 09:47 |
FIXED: Mystical (Has non-windows filenames) | Marcuz | project.Killergorilla's WHD packs | 12 | 03 August 2007 19:55 |
Windows filenames on CD | ptrchiappe | New to Emulation or Amiga scene | 19 | 26 February 2003 21:06 |
|
|