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

File.createTempFile incorrectly appended internally-generated chars in prefix

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Not an Issue
    • Icon: P4 P4
    • None
    • 6u31
    • core-libs
    • x86
    • windows_2003

      FULL PRODUCT VERSION :
      6.0.02 and 6.0.31

      ADDITIONAL OS VERSION INFORMATION :
      Windows Server 2003, 32bit

      A DESCRIPTION OF THE PROBLEM :
      Hi, we found out a very interesting issue in J2SE.

      We have the following line of Java code in our application for several years from Java version 6.0.02.
      xmlFile = File.createTempFile(millisecs + "." + getQueueName() + ".", ".messagetmp", outputFilePath);

      And the output of the xmlFile is something like:
      D:\Apps\abcd\working\MQ\xyz2receive\1330710671801.ABC.DEFGH.XYZ01.REQ.35907.messagetmp

      Our client recently upgraded the Java version from 6.0.02 to 6.0.31 and the output of the same Java line of code suddenly the generated xmlFile changed to:
      D:\Apps\abcd\working\MQ\xyz2receive\1331906116644.ABC.DEFGH.XYZ01.REQ.1371398464078825198.messagetmp
      So they are asking us why that long number before .messagetmp been changed from 5 digits to 19 digits.

      The following is the spec docs of createTempFile at http://docs.oracle.com/javase/6/docs/api/java/io/File.html#createTempFile(java.lang.String, java.lang.String, java.io.File)

        From this dosc, that long number at the end of prefix seems to be the five or more internally-generated characters. However we would like to know why we need adjustments in this case? For Windows server 2003 32bit operating system the allowed filename length should be 255 char long, but our filename even includes the directory is only about 100 characters or less. Also if adjustment is really needed, I don’t see the truncation on prefix happened either. We think in our case, regardless of Java version 6.0.02 or 6.0.31 we should not have such internally generated characters attached at the end of prefix.

      Thanks,
      Di

      createTempFile
      public static File createTempFile(String prefix,
                                        String suffix,
                                        File directory)
                                 throws IOException
      Creates a new empty file in the specified directory, using the given prefix and suffix strings to generate its name. If this method returns successfully then it is guaranteed that:
      1. The file denoted by the returned abstract pathname did not exist before this method was invoked, and
      2. Neither this method nor any of its variants will return the same abstract pathname again in the current invocation of the virtual machine.
      This method provides only part of a temporary-file facility. To arrange for a file created by this method to be deleted automatically, use the deleteOnExit() method.
      The prefix argument must be at least three characters long. It is recommended that the prefix be a short, meaningful string such as "hjb" or "mail". The suffix argument may be null, in which case the suffix ".tmp" will be used.
        To create the new file, the prefix and the suffix may first be adjusted to fit the limitations of the underlying platform. If the prefix is too long then it will be truncated, but its first three characters will always be preserved. If the suffix is too long then it too will be truncated, but if it begins with a period character ('.') then the period and the first three characters following it will always be preserved. Once these adjustments have been made the name of the new file will be generated by concatenating the prefix, five or more internally-generated characters, and the suffix.
      If the directory argument is null then the system-dependent default temporary-file directory will be used. The default temporary-file directory is specified by the system property java.io.tmpdir. On UNIX systems the default value of this property is typically "/tmp" or "/var/tmp"; on Microsoft Windows systems it is typically "C:\\WINNT\\TEMP". A different value may be given to this system property when the Java virtual machine is invoked, but programmatic changes to this property are not guaranteed to have any effect upon the temporary directory used by this method.
      Parameters:
      prefix - The prefix string to be used in generating the file's name; must be at least three characters long
      suffix - The suffix string to be used in generating the file's name; may be null, in which case the suffix ".tmp" will be used
      directory - The directory in which the file is to be created, or null if the default temporary-file directory is to be used
      Returns:
      An abstract pathname denoting a newly-created empty file
      Throws:
      IllegalArgumentException - If the prefix argument contains fewer than three characters
      IOException - If a file could not be created
      SecurityException - If a security manager exists and its SecurityManager.checkWrite(java.lang.String) method does not allow a file to be created
      Since:
      1.2


      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      You can easily write a small Java file to see what is the generated temp File as below.

      xmlFile = File.createTempFile(millisecs + "." + getQueueName() + ".", ".messagetmp", outputFilePath);

      In our system it generated D:\Apps\abcd\working\MQ\xyz2receive\1331906116644.ABC.DEFGH.XYZ01.REQ.1371398464078825198.messagetmp

      EXPECTED VERSUS ACTUAL BEHAVIOR :
      EXPECTED -
      Expect no internally generated chars to append in the end of prefix. So the generated temp file should be: D:\Apps\abcd\working\MQ\xyz2receive\1331906116644.ABC.DEFGH.XYZ01.REQ..messagetmp (please pay attention of double .. we added an extra . before .messagetmp because it always generates those appended numbers).
      ACTUAL -
      D:\Apps\abcd\working\MQ\xyz2receive\1331906116644.ABC.DEFGH.XYZ01.REQ.1371398464078825198.messagetmp

      ERROR MESSAGES/STACK TRACES THAT OCCUR :
      no error message.

      REPRODUCIBILITY :
      This bug can be reproduced always.

            alanb Alan Bateman
            webbuggrp Webbug Group
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: