See also anovak's WindowUtils.java 1.27: apparently '*' might be
unsafe as well.

Jesse asked me to post the list of characters that cause trouble in  
OpenVMS file names.

The problem with OpenVMS filenames stems from the fact that, while 
the OpenVMS operating system will support files with special 
characters in them, the OpenVMS JVM hasn't gotten around to providing 
that support yet.

So, the list I am providing for you is not a list of what characters 
are dangerous on OpenVMS per se, but what characters are dangerous 
when using the current OpenVMS JVM.

I worry that if a workaround is provided in NetBeans for this 
problem, it will never get properly fixed in our JVM.  This makes the 
quality of our JVM less than acceptable, in my view.  So, while I do 
greatly appreciate your willingness to work around this, 
I want you to know that it isn't a requirement on our part.

I decided it was easier to describe the characters that are allowed 
in the filename, rather than the ones that cause problems.

So, here is the current OpenVMS JVM view:
Ignoring directory specifications, a filename on OpenVM is made up of 
2 parts, the name and the extension.  The format is

        name.extension

name and extension can be made up of the following characters

        0-9                 // digits
        _                    // underscore
        -                     // dash
        a-z,A-Z          // letters

directory names follow exactly the same rules, i.e.

        0-9                 // digits
        _                    // underscore
        -                     // dash
        a-z,A-Z          // letters

so, it's not much....

Meg

Can there be directory names with an extension? File names without
one?

I agree this is a pretty limiting character set. It is difficult to
think of a reasonable character escape mechanism that would not force
escapes to be used even for common characters like '_'.

Another potential factor is that changing the escape character to one
which was previously not escaped at all (true for all OpenVMS chars
BTW) is backward compatibility of old instance files: normal
characters in them might be incorrectly assumed to be the starts of
escape sequences.

Adjusting mechanisms according to OS is probably not reasonable
because of the need to make NB projects directly portable across
systems.

Well, as far as directories having extensions...on OpenVMS, the full 
file specification looks like this:

   device:[dir.subdir1.subdir2.subdir3.etc]filename.extension;version

So, directories cannot have "." in them because it is part of the 
directory specifier syntax.  So, no, there is no "extension" for a 
directory name.  However, the directory file itself has an extension 
of .DIR.  So from the above example, if you ldid a "cd device:[dir]" 
and then did an "ls" you would see a file named subdir1.DIR.

The extension on the filespec is optional.  On OpenVMS a file without 
an extension still has a "." on the end of it...for example

   device:[dir]file_with_no_extension.

Our JVM translates OpenVMS filespecs into UNIX-like filespecs when 
necessary.  But the support for translating special characters from 
UNIX filespecs into OpenVMS filespecs hasn't been available.  That's 
what is being worked on now.  The actual work for this support is in 
our C runtime library (libc to you UNIX folks).

I suspect it will be available for us to test in the next couple of 
weeks.  But, then it must go through the red-tape of actually 
releasing it to customers on all the different OS versions.  This is 
where the time delay comes in for us.

One thing we're considering is to make beta versions of the C RTL 
available from our Compaq NetBeans website so that our customers can 
test NetBeans 3.3.

Meg
 

Have a patch...

Fixed.

committed   * Up-To-Date  1.28       
core/src/org/netbeans/core/windows/util/WindowUtils.java
committed   * Up-To-Date  1.96       
openide/src/org/openide/loaders/InstanceDataObject.java
committed   * Up-To-Date  1.14       
openide/test/unit/src/org/openide/loaders/InstanceDataObjectTest.java

Meg, when you get hold of an improved OpenVMS JVM I would definitely
recommend you run the complete xtest unit test suite on it, which will
include the test I just added that verifies that the generated
filenames are in fact safe for the OS you are running the test on.

I filed #17142 that this should be a general utility method, Tor you
may want to add yourself to the CC of that as well.

Resolved for 3.4.x or earlier, no new info since then -> verified

Resolved for 3.4.x or earlier, no new info since then -> closing.