Community
Participate
Working Groups
Build: I20060228-1207 File.create eagerly calls checkValidPath to determine if the path is valid for that OS. Investigate whether this check can be removed, and only used in the case of failure to improve performance for the common case where the path is valid.
In this matter we can't relay on OS because Eclipse is more restrictive when validating files. Take as an example files "nul" and "com3", java.io as well as DOS shell allow those files to be opened. Eclipse however throws CoreException in such case since those files are not represented in the filesystem. Another case is special handling of regular files. For exapmles on Windows it's possible to create "a " file but on the OS level the name is truncated and "a" is stored on the filesystem. Eclipse validation facility handles this situation not allowing for such a file to be created. See bug 118997 for details. Since only a part of validation could be moved to the place when we handle java.io call failure I suggest leaving the code as it is.
(In reply to comment #1) Agree. If John also agrees, let's mark it WONTFIX.
>Eclipse is more restrictive when validating files. Take as an example files >"nul" and "com3", java.io as well as DOS shell allow those files to be opened. I don't think this is true. Try this: new java.io.FileOutputStream(new java.io.File("c:\\tmp\\com3")); This fails for me. I also can't create a file called com3.txt from the DOS shell.
Created attachment 143013 [details] Creating com3 in DOS shell (In reply to comment #3) > I don't think this is true. Try this: > > new java.io.FileOutputStream(new java.io.File("c:\\tmp\\com3")); > > This fails for me. I also can't create a file called com3.txt from the DOS > shell. > OK, I should be more specific. This works in case you got something on com3 which is my case.
The method validating path takes 0.01% of File.create() execution time if files that we create are filled with small, random strings. If JVM is instructed not to compile to native code this raises to be 0.03%. Delegating part of the validation to the OS can save us roughly 40% of the Resource.checkValidPath(IPath, int, boolean) execution. This can drop to 20% if native code compilation is disabled. And this potential 40% could be taken of methods that create resources only whereas the method IWorkspace.validatePath(String, int) has to operate in the way it operates now. Beside the minimal performance improvement another problem is that the resulting code would be tangled. For example one would have to know that we need to check for illegal character ":" in resources code (because java.io creates a file "foo" when asked to create "foo:bar") while other illegal characters are checked on the OS level.
Since the gain is unnoticeable, I would leave the validation as it is now.
The investigation done shows that improvement is not worth implementing. See comment 1 and comment 5 for details.
