Bug ID: JDK-6176051 File.isFile() should return "false" for "con" on windows platform

Versions (Unresolved/Resolved/Fixed)

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	Other	JDK 6
1.4.2_17-revFixed	1.4.2_18Fixed	6 b73Fixed

There seems strange behavior of  isFile() in File class for special device files.

REPRODUCE :
  (1) Compile the attached program
  (2) Launch java command as follows on each platform
     1) Solaris and Linux
            Launch "java FiieCheck /dev/console"
     2) Windows
            Launch "java FileCheck con"
   
RESULT :
    In (2) 1), the  test program returns "false", but in(2) 2),  returns true.

REQUESTs :
   "con" represents console on windows
   but done as normal file.
   That should be treated as special file as on Solaris/linux.

CONFIGURATION :
   JRE : 
     java version "1.5.0"
     Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
     Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode)
   Platform :
       - WindowsXP SP1(japanese )
       - RedHatlinux 9.0(japanese)
       - Solaris 8(japanese)
###@###.### 10/8/04 07:54 GMT
###@###.### 10/15/04 01:22 GMT

EVALUATION GetFileAttributesEx does not work for PRN and LPT1 on XP Home Edition with SP1/2, so it is not reliable solution if we only depends on GetFileAttributesEx. The approach we are now using is to (1)first call GetFullPathName to check if the fullpath is in format of \\.\<DevName>, then lookup DevName against a predefined Windows reserved device name table. (2)then use GetFileAttributesEx to double check anything that is not picked up by (1)

31-01-2006

EVALUATION I suspect that we can fix this problem by modifying our native implementation of getBooleanAtrributes() to call GetFileAttributesExW instead of GetFileAttributesW. I've tested the "Ex" version which will returns "false" for "con" and a populated structure for the file attributes for other files. The native code will have to be changed slightly to handle the new boolean return value for the "Ex" function. But the "dwFileAttributes" member of the WIN32_FILE_ATTRIBUTES_DATA struct is the same as the value returned by the old API, so the code doesn't need to be modified that much... maybe 2-3 lines.

25-10-2005

EVALUATION It is not obvious from first principles whether isFile() should return true or false for special files. Certainly this is an area where a Java implementation has the right to do something system-dependent. That said, it would be nice if Solaris and Windows behavior for things like con and /dev/console were consistent. However, compatibility of installed applications over time with newer JVMs trumps the much more vague notion of compatibility between systems as diverse as windows and unix. Most likely, I will close this as "Will not Fix". ###@###.### 10/15/04 01:22 GMT

08-10-2004

Relates :	JDK-6655911 - Remove java/io/File/WinDeviceName.java from 1.4.2_17 regression testbed
Relates :	JDK-4858457 - File.getCanonicalPath() throws IOException when invoked with "nul" (win)
Relates :	JDK-8022671 - Revisit the Logic of Handling Devices In Java IO/NIO Functions
Relates :	JDK-4190157 - using "Con" as a class name causes a problem (reserved filename in Win32)