JDK-4778561 : REGRESSION:General exhaustive test of win32 pathname handling
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 1.3.1_07
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: x86
  • Submitted: 2002-11-14
  • Updated: 2002-12-05
  • Resolved: 2002-12-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.3.1_07 07Fixed
Related Reports
Relates :  
JDK-4032066 - java.io: File classes do not recognize Windows UNC filenames (win32)
Relates :  
JDK-4185525 - java.io: Cannot create files with full Unicode names (Win32/NT)
Description
Fix for bug # 4185525 in 1.3.1_07 b01 casued a regression.

test/java/io/pathNames/GeneralWin32.java  

testcase FAILED with 1.3.1_07 b01 while it's passed with previour releases.

It throws java.io.FileNotFoundException. 

Attached is the standalone testcase extracted from regression testsuite.

Steps:
1. Compile *.java
2. java GeneralWin32

It's only for Windows platform.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.3.1_07 FIXED IN: 1.3.1_07 INTEGRATED IN: 1.3.1_07
14-06-2004
SUGGESTED FIX ------- RandomAccessFile.java ------- 82,93c82 < boolean rw = mode.equals("rw"); < if (!rw && !mode.equals("r")) < throw new IllegalArgumentException("mode must be r or rw"); < SecurityManager security = System.getSecurityManager(); < if (security != null) { < security.checkRead(name); < if (rw) { < security.checkWrite(name); < } < } < fd = new FileDescriptor(); < open(name, rw); --- > this(new File(name), mode); 138c127,139 < this(file.getPath(), mode); --- > String name = file.getPath(); > boolean rw = mode.equals("rw"); > if (!rw && !mode.equals("r")) > throw new IllegalArgumentException("mode must be r or rw"); > SecurityManager security = System.getSecurityManager(); > if (security != null) { > security.checkRead(name); > if (rw) { > security.checkWrite(name); > } > } > fd = new FileDescriptor(); > open(name, rw); ------- FileInputStream.java ------- 54,59c54 < SecurityManager security = System.getSecurityManager(); < if (security != null) { < security.checkRead(name); < } < fd = new FileDescriptor(); < open(name); --- > this(new File(name)); 90c85,91 < this(file.getPath()); --- > String name = file.getPath(); > SecurityManager security = System.getSecurityManager(); > if (security != null) { > security.checkRead(name); > } > fd = new FileDescriptor(); > open(name); ------- FileOutputStream.java ------- 57c57 < this(name, false); --- > this(new File(name), false); 89,98c89 < SecurityManager security = System.getSecurityManager(); < if (security != null) { < security.checkWrite(name); < } < fd = new FileDescriptor(); < if (append) { < openAppend(name); < } else { < open(name); < } --- > this(new File(name), append); 127c118 < this(file.getPath()); --- > this(file, false); 129a121,138 > /* > * The following is an API since JDK 1.4, but not before. So this is private. > */ > > private FileOutputStream(File file, boolean append) throws FileNotFoundException { > String name = file.getPath(); > SecurityManager security = System.getSecurityManager(); > if (security != null) { > security.checkWrite(name); > } > fd = new FileDescriptor(); > if (append) { > openAppend(name); > } else { > open(name); > } > } > ###@###.### 2002-11-14
14-11-2002
EVALUATION To fix 4185525 (Cannot create files with Unicode names in WinNT) for 1.3.1_07, WinNTFileSystem.java and associated native code changes were backported from 1.4.0 to 1.3.1_07. Unit test case and JCK - API tests went through without any problems. But I verified that the regression test fails as reported in this bug. It failes for file names such as "t.java/.\". In 1.4.0 codebase, constructors of FileInputStream, FileOutputStream and RandomAccessFile have been changed. String accepting constructors of these classes create new java.io.File out of the file name argument and pass file.getPath() to native open method. Whereas in 1.3.1 code, string is directly passed to native open method. Till 1.3.1_06 only Win32FileSystem was supported. This file system itself handled cases such as t.java/.\. The new WinNTFileSystem does not handle such names. The fix is to change constructors of FileInputStream, FileOutputStream and RandomAccessFile classes along the lines of 1.4.0 code. Please refer to "Suggested Fix". I verified that this fix. I'll work on getting this fix into 1.3.1_07. ###@###.### 2002-11-14
14-11-2002