1

I'm creating temporary directories with

Files.createTempDirectory(String.format("project-it-screenshots-%d",
        System.currentTimeMillis())).toFile();

an I assumed that the longs returned by System.currentTimeMillis() all have the same length because two return values with different length have to come from different centuries. After invoking the method multiple times per day I ended up with

project-it-screenshots-15343380422205011345585140911467
project-it-screenshots-15343381444485756307954062111474
project-it-screenshots-15343386111604255833362898885857
project-it-screenshots-15343388402055473274775132302475
project-it-screenshots-1534338974370463603854456850155
project-it-screenshots-15343390449093279576023746896269
project-it-screenshots-15343398036346426501075034038757
project-it-screenshots-15343399888498609875231360701639
project-it-screenshots-15343401211515574289310135012571
project-it-screenshots-15343405563586337945661543042110
project-it-screenshots-15343419027757787065954653813302
project-it-screenshots-15343425353682119990056938907868
project-it-screenshots-15343429571018010152043055630277
project-it-screenshots-15343431608662744493593200651167
project-it-screenshots-15343436122094379676346949668973
project-it-screenshots-15343442103124076542522856351947
project-it-screenshots-15343539846818150078805796257638
project-it-screenshots-15343555678106536264262565060437
project-it-screenshots-15343809068582300780873443756155
project-it-screenshots-15344378068483088975615680511653
project-it-screenshots-15344421866441533761733546877922

where 1534338974370463603854456850155 is one digit shorter than the others. This seems to be unrelated to stripping of leading 0s because there're none and to trailing 0s because some numbers with the larger length have them and others don't.

I'm searching for an explanation, not a workaround (I'll use a formatted date which can be sorted or add 0 padding to the number with String.format which only changes the timestamp slightly).

I'm using OpenJDK 8 on Ubuntu 18.04.

Kalle Richter
  • 8,008
  • 26
  • 77
  • 177
  • `createTempDirectory` adds a bunch of "unique" suffix characters, and that's implementation dependent, unspecified. See https://stackoverflow.com/questions/9594886/how-to-create-a-temp-file-in-java-without-the-random-number-appended-to-the-file – Sotirios Delimanolis Aug 16 '18 at 18:27
  • In all of your examples the result from `currentTimeMillis` has gone into the first 13 digits (no more, no less), for example `1534338042220` and `1534338974370`. All of your millisecond values form a nice increasing sequence. – Ole V.V. Aug 18 '18 at 07:35

1 Answers1

4

The method System.currentTimeMillis() returns a long, which can only be a maximum of 19 digits long. But your numeric strings are 31-32 characters long.

The call to Files.createTempDirectory() is adding additional characters to your filename.

Creates a new directory in the default temporary-file directory, using the given prefix to generate its name.

(bold emphasis mine)

This method works in exactly the manner specified by createTempDirectory(Path,String,FileAttribute[]) method for the case that the dir parameter is the temporary-file directory.

And that method states:

The details as to how the name of the directory is constructed is implementation dependent and therefore not specified.

If you want the name to be predictable, then you can't use any of the "createTemp" methods in Files. If you're okay with the suffix not being in your control, then it is optional how you can create your prefix. But using System.currentTimeMillis() is not the reason pathname is shorter than the other. It must be the implementation, which is not specified.

On Windows 10, I get something similar.

C:\Users\rgettman\AppData\Local\Temp\project-it-screenshots-15344437949188484678689730417470
rgettman
  • 176,041
  • 30
  • 275
  • 357