Advanced Server - Problem with multi-byte code page

[Ted Ripp]

AS V7.3A for OpenVMS
VMS V7.3-1
Directory Share on ODS-5
AS language English (USA)

I have a user with a .PDF file named l's.pdf. When he tries to copy that file using Windows Explorer to the AS share he gets: Cannot copy l's: No mapping for the Unicode character exists in the target multi-byte code page.

I can copy this file to a Windows file server or to my desktop without problems.

If I rename the file and remove the apostrophe I can copy the file to the AS share. If I create a different file with the same name I can copy that file to the AS share. If I right click the file and erase the file name completely and then type the name back in as l's I can copy the file to the AS share. This seems odd since I start with l's erase the name and then type in l's and the file can now be copied.


Thanks in advance,
Ted Ripp

[Ted Ripp]

PS

I tried to attach the file that I could not copy to my posting above but the file name got changed, so it is of no value I suspect.

TR

[Wim Van den Wyngaert]

Don't have anything comparable but I guess :
The file is origibally created with a name that is stored in Unicode (2 bytes for each character). When you try to copy the unicode filename to VMS there should be made a translation and that's what's missing.

Wim

[Antoniov.]

Hi Ted,
I guess the trouble is apostrophe ' characters that under vms is macro substitution; I think vms try to translate the s into something and substitution fails.

Antonio Vigliotti

[Bill Hall]

Ted,

I just tested a share on a V7.3-2 cluster with all current ECOs installed and AdvancedSserver 7.3A ECO3. I was able to copy a file with an apostrophe in the filename. From DCL the filename looks like I would expect on an ODS-5 volume:

webes_i^'s.pdf;1

I don't specifically recall this being noted as fixed in the release notes. Might be the combination of VMS version, ECOS and AS ECO.

Bill

[Ted Ripp]

I have ECO3 installed.


If I create a file named l's.pdf I can copy it to the AS share. There is something special about the particular file named l's.pdf that I am testing with that prevents it from being copied to the AS share. Like I said above, the file will not copy but if I erase the name completely and then reenter it as l's.pdf I can copy it. There must be something about this particular Windows file name that is invisible that prevents it from being copied. I am using Windows 2000.

TR

[Bill Hall]

Somewhere in the original filename there is a non-printable/invisible Unicode character that you can't "see". Renaming the file to the character string that is visible to you can then can be copied to AS. I'm sure only Microsoft can tell you how your user created the original filename.

[Jan van den Ende]

Ted,

if you are able to re-create a file WITH the problem (preferably in a not-to-populated directory), an then you DUMP the .DIR file(/output=, then, if there really is a spurious character, it will show up.
If it is not obvious, re-erase and re-name the file (visibly) the same, and DUMP again.
Compare, and I would be surprised if it shows the same filename string.
---- considering the way filenames are stored in directories, make sure the first character of your filename is unique in the directory, or be prepared to have a lot of extra manipulations to be done to locate your file.


hth


Jan

[Martin P.J. Zinser]

Hello Jan,

the concept of your post is ok, the implementation not ;-)

As far as I understand it the file with the incrimating name is located on a Windows served disk and there is no way to get it with this name to the VMS (AS) served disk. So what Ted needs is a "dump" of the directory on Windows.
Maybe one can load a copy of the directory file on windows into a hex editor?

Greetings, Martin

[Brad McCusker]

I agree with other posters - there is something in that name that you can't "see".

Perhaps some Windows gurus might be able to point you to some tools that will do something like Jan suggested, except on Windows.

My only suggestion would be to get a network trace of the attempted copy. You shouldbe able to see the actual bytes that make up the file name that way. If its worth the effort to you.

Brad