United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6176051 File.isFile() should return "false" for "con" on windows platform
JDK-6176051 : File.isFile() should return "false" for "con" on windows platform

Details
Type:
Bug
Submit Date:
2004-10-08
Status:
Closed
Updated Date:
2013-08-08
Project Name:
JDK
Resolved Date:
2006-02-18
Component:
core-libs
OS:
generic
Sub-Component:
java.io
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
5.0u1
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
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

                                    

Comments
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
                                     
2004-10-08
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.
                                     
2005-10-25
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)
                                     
2006-01-31



Hardware and Software, Engineered to Work Together