JDK-4102262 : java.io.File: Inconsistent filename normalization (win32)
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 1.2.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_95,windows_nt
  • CPU: x86
  • Submitted: 1998-01-07
  • Updated: 1999-01-15
  • Resolved: 1999-01-15
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.2.0 1.2beta4Fixed
Related Reports
Duplicate :  
Relates :  
Description

Name: dgC58589			Date: 01/07/98


I'm an old Unix hacker. I grew up with forward
slashes separating levels in a path. I'm trying
to avoid becoming a Windows hacker by becoming a
Java hacker. But unfortunately, the separator
character is being treated inconsistently in
java.io (and awt). I lived with it in jdk1.1, but
its time to make some noise... the inconsistency
is causing me too much pain. :o)

For instance: if I create a File with a path
in a string with forward-slash separated levels
and open it (let's say by creating a
RandomAccessFile) everything's cool. That is
until I do a getParent() on the File; instead of
using the forward slashes, its using the native
separatorChar. Yack. (I've had to do some fairly
ugly path munging in subclasses of java.io to get
things to hand off in a platform independent way;
it works, but its not transparent.)

Or how about this: pass a mkdirs() message to a
File created with a forward slash separated
levels which needs a few levels of directory
created on Windows95:

  boolean createdDirectories =
    (new File("C:/foo/bar/mumble/theFile")).
    mkdirs();

Check out different values for the expression
when either nothing, only foo, foo/bar,
foo/bar/mumble, or foo/bar/mumble/theFile exist.
If there's no security violation, all of the
calls should create whatever's necessary (even if
nothing had to be created) and return true.
Because of the inconsistency with the forward
slashes, mkdirs doesn't work unless you first
convert the path to an machine-dependent
representation. Yack again. Java should do this.

The problem is that Java should either do it all
everywhere (converting to a universal separator -
might I suggest a forward slash?) or make the
developer do it all (dealing with all of the
platform dependencies.) Doing only some of it and
making the developer discover (by trial and
error) what works and what doesn't is a real
pisser.

Or, at least as a stopgap add pathNormalize() and
pathUnnormalize() to file so the filtering is in
the right object.
(Review ID: 22667)
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic FIXED IN: 1.2beta4 INTEGRATED IN: 1.2beta4
14-06-2004

WORK AROUND Name: dgC58589 Date: 01/07/98 Ugly code either in subclasses, or at too high a level (in application code.) ======================================================================
11-06-2004

EVALUATION The java.io.File class should really deal with Win32 pathnames in a more graceful fashion. The best way to fix this is probably to introduce some private, platform-specific Java classes. -- mr@eng 1/21/1998 Fixed. The File class has been respecified to represent pathnames in a much more abstract way (4131169). -- mr@eng 5/14/1998
21-01-1998