JDK-4723726 : URI.normalize() ruins URI built from UNC File
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 1.4.1,1.4.2,5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic,windows_2000,windows_xp
  • CPU: generic,x86
  • Submitted: 2002-07-31
  • Updated: 2010-08-14
  • Resolved: 2010-08-14
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
Name: nt126004			Date: 07/31/2002


FULL PRODUCT VERSION :
java version "1.4.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-beta-b14)
Java HotSpot(TM) Client VM (build 1.4.1-beta-b14, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]
Service Pack 2


A DESCRIPTION OF THE PROBLEM :
Calling URI.normalize() on a URI that was derived from a
file that is a UNC will ruin the URI.

I understand that URI.normalize() follows RFC 2396, and I have no problem with
that. I guess the issue is that File.toURI() creates a URI that may not 
conform to the spec.  If I do not normalize the URI I can use the URI to 
create a File object later that correctly points to the UNC and I can access 
it.  Once normalize() has been called, and I want to call it to be sure
I have unique URIs for unique files, the File I construct from the URI will 
no longer be able to access the UNC file.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Run the test program.

EXPECTED VERSUS ACTUAL BEHAVIOR :
Start File:    \\S840700\pub\request.asp
Start URI:     file:////S840700/pub/request.asp

After normalization.
Result URI:    file:/S840700/pub/request.asp
Result File:   \S840700\pub\request.asp

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.io.File;
import java.net.URI;

public class TestFile {

	public static final void main( String[] aaParamters ) {
		File oStartFile = new File( "\\\\S840700\\pub\\request.asp" );
		URI oStartURI = oStartFile.toURI();
		String sStartString = oStartURI.toString();

		System.out.println( "Start File:    " + oStartFile );
		System.out.println( "Start URI:     " + oStartURI );

		URI oURI = oStartURI.normalize();
		File oFile = new File( oURI );

		System.out.println( "After normalization." );
		System.out.println( "Result URI:    " + oURI );
		System.out.println( "Result File:   " + oFile );
	}

}
---------- END SOURCE ----------
(Review ID: 159930) 
======================================================================
###@###.### 10/13/04 06:29 GMT

Comments
EVALUATION This can't be fixed without potentially breaking existing code. A note on this issue, and a workaround for new code to use toPath().toUri(), has already been added to File.toURI's javadoc for jdk7.
14-08-2010

EVALUATION .
24-07-2009

EVALUATION The workaround, for jdk7, is to create URIs using f.toPath().toUri(). This will yield a URI with the UNC server name in the authority component as developers expect. Note that File#toURI cannot be changed to do this because the method is specified to yield a URI with an undefined authority component. Furthermore it would likely break a lot of existing code that incorrectly assumes the URI's path component can be used as a file path. Alternatively f.toPath().normalize() as that will normalize the path without needing to create a URI (this may be what the original submitter was seeking). The remaining issue for 4723726 is how URI#normalize method should behave when created with URIs such as "file:////server/foo". The method is specified to follow the normalization steps of RFC 2396 and is therefore working as specified. That is, the correct result is file:/server/foo. I would suggest that we close this one as "will not fix".
20-07-2009

EVALUATION I agree with previous evaluation. File.toRUI() does not appear to return the properly formed URI. It specifically sets the host to 'null' while creating the URI. Re-assigning to classes_io.
06-07-2009

EVALUATION Seems to me that the logical URI in this case would be path vvvvvvvvvvvvvvvv file://S840700/pub/request.asp ^^^^^^^ host This is also consistent with what IE does, which I would consider an authoritative source (especially if you wish to use e.g. Desktop.browse): http://blogs.msdn.com/ie/archive/2006/12/06/file-uris-in-windows.aspx The current behavior of the JRE is specifically listed in this posting as a mistake. Check also .NET conventions: http://msdn.microsoft.com/en-us/library/system.uri.isunc.aspx
28-05-2008

EVALUATION It looks like File.toURI() works correctly -- the problem here seems to be that URI.normalize() is removing too many slashes. Forwarding to classes_net. -- ###@###.### 2002/7/31 Normalization is removing empty path segments and is not aware of the Windows specific convention for UNCs. This seems more appropriate to re-visit in tiger. ###@###.### 2002-08-01
01-08-2002