Windows code page and OEM character sets used on Japanese-language systems contain the Yen symbol (¥) instead of a backslash (\). Thus, the Yen character is a prohibited character for those file systems. When mapping Unicode to a Japanese-language code page, conversion functions map both backslash (U+005C) and the normal Unicode Yen symbol (U+00A5) to this same character. For security reasons, your applications should not typically allow the character U+00A5 in a Unicode string that might be converted for use as a FAT file name.

The above is a quotation. My observation is that security isn’t the only reason to hesitate on whether to allow the character U+00A5. As mentioned before, even in cases where security isn’t (or shouldn’t) be a problem, Windows sometimes has problems.

Here is where that quotation came from:

http://msdn2.microsoft.com/en-us/library/ms776406(VS.85).aspx

Wednesday, April 16, 2008 4:01 AM by ndiamond

The strange things that happen with U+00A5 still happen with U+00A5; I typed that one correctly.

Monday, March 03, 2008 10:31 PM by ndiamond

“com5 The above file name is invalid.”

You are right, the common dialog box does distinguish those. I wonder why. I had tested com4: and com5: with colons, and the common dialog box gives identical error messages in those cases. Also in my experience with other areas of XP, error messages for com4 and com5 are identical (except of course when com4 or com5 exists).

“I suspect that you are confusing the U+00A5 Unicode character code point with” [with the yen sign ANSI 0xC5]. Well, the yen sign ANSI 0xC5 (which exists in ANSI code page 932 only) is indeed U+00A5, no confusion on my part. Windows has to convert this to U+005C instead of U+00A5 because it’s more important to interpret this as a path separator instead of the actual character, no confusion on anyone’s part. But last year, investigating a bug report from a beta tester, I had to do some experimenting with filenames in XP. I created some pathnames that included U+00A5. Windows Explorer indeed displayed it with the same glyph as the ordinary yen glyph for path separator. Meanwhile some parts of Windows XP were mighty confused by those pathnames. Some users don’t even get their Start menus displayed properly.

“I suspect that you incorrectly misinterpreted I[19]. By entering C:\ you are actually entering a path component to the base file name component which is also a common mistake.”

I see your point, but I’m still confused. By entering a \ at all I am entering a path component. Even if \ is in the first position it is a path component, specifying the current drive’s root directory instead of the default current directory. I still don’t see how it can be correct for I[19] to distinguish a \ in the first position from a \ in any other position. I do understand (being reminded by your comment) that the basename begins after the last \.

“the semicolon is not an invalid character in the file name basename parameter”

You and I agree, but XP’s Windows Explorer sometimes disagrees. I couldn’t get the same error from a common dialog box though.

Sunday, March 02, 2008 8:56 PM by ndiamond

Actually, when one types the literal string COM4 into the File name combobox control on an English version of Windows Xp an error message from COMDLG32.DLL appears stating “com4 This file name is a reserved device name. Please choose anothher name.” That is Invalid class subset I[4]. When one types the literal string COM5 into the File name combobox control on an English version of Windows Xp an error message from COMDLG32.DLL appears stating, “com5 The above file name is invalid.”

Honestly, I am not sure how anyone can confuse those two error messages, but that’s not really important. What is important is that I discovered this anomoly in error handling and the issue is resovled in Windows Vista.

V[5] includes the Unicode character code point U+00A5 which is the Yen sign. I suspect that you are confusing the U+00A5 Unicode character code point with the glyph that appears on a Japanese language version when one types the backslash character on a keyboard which actually generates a U+005C Unicode character code point (but looks like the Yen sign). (BTW…on a Korean version the glyph displayed for the U+005C Unicode character code point looks like the Won sign.) But, again, at the GUI on a Japanese language version the U+005C and U+00A5 glyphs look the same, so I can understand how it might be confusing.

Actually, I[19] is not defective. I suspect that you incorrectly misinterpreted I[19]. By entering C:\ you are actually entering a path component to the base file name component which is also a common mistake. It also assumes a bit of common sense.

Experiementation is good, but you appear to have strayed from the primary purpose of systematically evaluating the basename parameter and moved to the next level of trying various combinations and permutations of invalid and valid subsets that exercise the file name components including the path, the base filename, and the extension components. This is a common occurance, in systematic testing. People sometimes become more engaged in finding wild off the wall random stuff, or they easily get distracted by “hey ya’ll let’s try this” type mentality that basic functionality of a parameter is sometimes overlooked occasionally resulting in defects that have greater impact to the user.

Oh…and sometimes meteors fall to earth, but the semicolon is not an invalid character in the file name basename parameter which of course is the stated purpose for this systematic decomposition of the specified data set.

Friday, February 29, 2008 2:20 PM by I.M.Testy

V[5] includes Latin 1’s code point for a version of the yen sign, but Windows XP sometimes has trouble with that character. Are you sure it’s supposed to be a valid character instead of invalid?

I[19] is defective. In Notepad, I could specify the following path in Save as:

“C:\x.txt”

It worked.

Seeing some of the overlaps and omissions in your I sets, I tried an experiment. In Notepad, I set the filter to all files, and tried to save a file to:

“\\?\C:\txt.”

For comparison, in a command prompt window I can copy to that pathname to create the file, and can delete that file, as long as I specify the path that way. So today, I tried it in Notepad’s “Save as” dialog box. Oh… while I was typing this, Notepad finally retorted that the pathname is invalid. I thought I was going to have to kill it from task manager.

(Off-topic: Sometimes the Windows shell says that semicolon is an invalid character, though I don’t think that happens in the basename parameter in an API call.)

Thursday, February 28, 2008 10:18 PM by ndiamond