Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6176051

File.isFile() should return "false" for "con" on windows platform

    Details

    • Subcomponent:
    • Resolved In Build:
      b73
    • CPU:
      generic
    • OS:
      generic
    • Verification:
      Verified

      Backports

        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

          Issue Links

            Activity

            Hide
            tbaba Tadayuki Baba (Inactive) added a comment -
            BT2: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
            Show
            tbaba Tadayuki Baba (Inactive) added a comment - BT2: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
            Hide
            iris Iris Clark added a comment -
            BT2: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.
            Show
            iris Iris Clark added a comment - BT2: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.
            Hide
            sherman Xueming Shen added a comment -
            BT2: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)
            Show
            sherman Xueming Shen added a comment - BT2: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)

              People

              • Assignee:
                sherman Xueming Shen
                Reporter:
                tbaba Tadayuki Baba (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: