Jak utworzyć tymczasowy katalog / folder w Javie?

Czy istnieje standardowy i niezawodny sposób tworzenia katalogu tymczasowego w aplikacji Java? W bazie danych problemów Javy jest wpis , który zawiera trochę kodu w komentarzach, ale zastanawiam się, czy istnieje standardowe rozwiązanie w jednej ze zwykłych bibliotek (Apache Commons itp.)?

Jeśli używasz JDK 7, użyj nowej klasy Files.createTempDirectory, aby utworzyć katalog tymczasowy.

Path tempDirWithPrefix = Files.createTempDirectory(prefix);

Przed JDK 7 powinno to zrobić:

public static File createTempDirectory()
    throws IOException
{
    final File temp;

    temp = File.createTempFile("temp", Long.toString(System.nanoTime()));

    if(!(temp.delete()))
    {
        throw new IOException("Could not delete temp file: " + temp.getAbsolutePath());
    }

    if(!(temp.mkdir()))
    {
        throw new IOException("Could not create temp directory: " + temp.getAbsolutePath());
    }

    return (temp);
}

Możesz zrobić lepsze wyjątki (podklasa IOException), jeśli chcesz.

Biblioteka Google Guava ma mnóstwo przydatnych narzędzi. Jedną z ważniejszych tutaj jest klasa Files . Ma wiele przydatnych metod, w tym:

File myTempDir = Files.createTempDir();

Robi dokładnie to, o co prosiłeś w jednym wierszu. Jeśli przeczytasz tutaj dokumentację , zobaczysz, że proponowana adaptacja File.createTempFile("install", "dir")zwykle wprowadza luki w zabezpieczeniach.

Jeśli potrzebujesz tymczasowego katalogu do testowania i używasz jUnit, @Rulerazem z TemporaryFolderrozwiązaniem problemu:

@Rule
public TemporaryFolder folder = new TemporaryFolder();

Z dokumentacji :

Reguła TemporaryFolder umożliwia tworzenie plików i folderów, które z pewnością zostaną usunięte po zakończeniu metody testowej (niezależnie od tego, czy przejdzie, czy nie)

Aktualizacja:

Jeśli używasz JUnit Jupiter (wersja 5.1.1 lub nowsza), możesz skorzystać z JUnit Pioneer, który jest pakietem rozszerzeń JUnit 5.

Skopiowano z dokumentacji projektu :

Na przykład poniższy test rejestruje rozszerzenie dla pojedynczej metody testowej, tworzy i zapisuje plik w katalogu tymczasowym oraz sprawdza jego zawartość.

@Test
@ExtendWith(TempDirectory.class)
void test(@TempDir Path tempDir) {
    Path file = tempDir.resolve("test.txt");
    writeFile(file);
    assertExpectedFileContent(file);
}

Więcej informacji w JavaDoc i JavaDoc w TempDirectory

Stopień:

dependencies {
    testImplementation 'org.junit-pioneer:junit-pioneer:0.1.2'
}

Maven:

<dependency>
   <groupId>org.junit-pioneer</groupId>
   <artifactId>junit-pioneer</artifactId>
   <version>0.1.2</version>
   <scope>test</scope>
</dependency>

Aktualizacja 2:

@TempDir Adnotacja dodano do JUnit Jupiter 5.4.0 uwalniania jako funkcję doświadczalnej. Przykład skopiowany z Podręcznika użytkownika JUnit 5 :

@Test
void writeItemsToFile(@TempDir Path tempDir) throws IOException {
    Path file = tempDir.resolve("test.txt");

    new ListWriter(file).write("a", "b", "c");

    assertEquals(singletonList("a,b,c"), Files.readAllLines(file));
}

Naiwnie napisany kod rozwiązujący ten problem cierpi z powodu warunków wyścigowych, w tym kilku odpowiedzi tutaj. Historycznie można było dokładnie przemyśleć warunki wyścigu i napisać je samodzielnie, lub użyć biblioteki innej firmy, takiej jak Google Guava (jak sugeruje odpowiedź Spiny). Możesz też napisać błędny kod.

Ale od JDK 7 są dobre wieści! Sama standardowa biblioteka Java zapewnia teraz poprawnie działające (nieratyczne) rozwiązanie tego problemu. Chcesz java.nio.file.Files # createTempDirectory () . Z dokumentacji :

public static Path createTempDirectory(Path dir,
                       String prefix,
                       FileAttribute<?>... attrs)
                                throws IOException

Tworzy nowy katalog w określonym katalogu, używając podanego prefiksu do wygenerowania jego nazwy. Wynikowa ścieżka jest powiązana z tym samym systemem plików co dany katalog.

Szczegóły budowy nazwy katalogu zależą od implementacji i dlatego nie są określone. Tam, gdzie to możliwe, przedrostek służy do konstruowania nazw kandydatów.

To skutecznie rozwiązuje zawstydzająco starożytny raport o błędach w module śledzenia błędów Sun, który poprosił o taką właśnie funkcję.

To jest kod źródłowy Files.createTempDir biblioteki Guava. Nie jest to tak skomplikowane, jak mogłoby się wydawać:

public static File createTempDir() {
  File baseDir = new File(System.getProperty("java.io.tmpdir"));
  String baseName = System.currentTimeMillis() + "-";

  for (int counter = 0; counter < TEMP_DIR_ATTEMPTS; counter++) {
    File tempDir = new File(baseDir, baseName + counter);
    if (tempDir.mkdir()) {
      return tempDir;
    }
  }
  throw new IllegalStateException("Failed to create directory within "
      + TEMP_DIR_ATTEMPTS + " attempts (tried "
      + baseName + "0 to " + baseName + (TEMP_DIR_ATTEMPTS - 1) + ')');
}

Domyślnie:

private static final int TEMP_DIR_ATTEMPTS = 10000;

Spójrz tutaj

Nie używaj, deleteOnExit()nawet jeśli później usuniesz go wyraźnie.

Google „deleteonexit is evil”, aby uzyskać więcej informacji, ale sedno problemu to:

1. deleteOnExit() usuwa tylko w przypadku normalnego zamykania JVM, nie powoduje awarii ani nie zabija procesu JVM.

2. deleteOnExit() usuwa tylko przy zamykaniu JVM - nie nadaje się do długotrwałych procesów serwera, ponieważ:

3. Najbardziej zło ze wszystkich - deleteOnExit()zużywa pamięć dla każdego wpisu pliku tymczasowego. Jeśli proces trwa kilka miesięcy lub w krótkim czasie utworzysz wiele plików tymczasowych, zużywasz pamięć i nigdy jej nie zwalniasz, dopóki JVM nie wyłączy się.

Od wersji Java 1.7 createTempDirectory(prefix, attrs)i createTempDirectory(dir, prefix, attrs)są zawarte wjava.nio.file.Files

Przykład: File tempDir = Files.createTempDirectory("foobar").toFile();

Oto, co postanowiłem zrobić dla własnego kodu:

/**
 * Create a new temporary directory. Use something like
 * {@link #recursiveDelete(File)} to clean this directory up since it isn't
 * deleted automatically
 * @return  the new directory
 * @throws IOException if there is an error creating the temporary directory
 */
public static File createTempDir() throws IOException
{
    final File sysTempDir = new File(System.getProperty("java.io.tmpdir"));
    File newTempDir;
    final int maxAttempts = 9;
    int attemptCount = 0;
    do
    {
        attemptCount++;
        if(attemptCount > maxAttempts)
        {
            throw new IOException(
                    "The highly improbable has occurred! Failed to " +
                    "create a unique temporary directory after " +
                    maxAttempts + " attempts.");
        }
        String dirName = UUID.randomUUID().toString();
        newTempDir = new File(sysTempDir, dirName);
    } while(newTempDir.exists());

    if(newTempDir.mkdirs())
    {
        return newTempDir;
    }
    else
    {
        throw new IOException(
                "Failed to create temp dir named " +
                newTempDir.getAbsolutePath());
    }
}

/**
 * Recursively delete file or directory
 * @param fileOrDir
 *          the file or dir to delete
 * @return
 *          true iff all files are successfully deleted
 */
public static boolean recursiveDelete(File fileOrDir)
{
    if(fileOrDir.isDirectory())
    {
        // recursively delete contents
        for(File innerFile: fileOrDir.listFiles())
        {
            if(!FileUtilities.recursiveDelete(innerFile))
            {
                return false;
            }
        }
    }

    return fileOrDir.delete();
}

Cóż, „createTempFile” faktycznie tworzy plik. Dlaczego więc najpierw go nie usunąć, a następnie wykonać na nim mkdir?

Ten kod powinien działać dość dobrze:

public static File createTempDir() {
    final String baseTempPath = System.getProperty("java.io.tmpdir");

    Random rand = new Random();
    int randomInt = 1 + rand.nextInt();

    File tempDir = new File(baseTempPath + File.separator + "tempDir" + randomInt);
    if (tempDir.exists() == false) {
        tempDir.mkdir();
    }

    tempDir.deleteOnExit();

    return tempDir;
}

Jak omówiono w tym RFE i jego komentarzach, możesz zadzwonić jako tempDir.delete()pierwszy. Lub możesz użyć System.getProperty("java.io.tmpdir")i utworzyć tam katalog. Tak czy inaczej, pamiętaj, aby zadzwonić tempDir.deleteOnExit(), w przeciwnym razie plik nie zostanie usunięty po zakończeniu.

Na zakończenie jest to kod z biblioteki Google guava. To nie jest mój kod, ale myślę, że warto go pokazać tutaj w tym wątku.

  /** Maximum loop count when creating temp directories. */
  private static final int TEMP_DIR_ATTEMPTS = 10000;

  /**
   * Atomically creates a new directory somewhere beneath the system's temporary directory (as
   * defined by the {@code java.io.tmpdir} system property), and returns its name.
   *
   * <p>Use this method instead of {@link File#createTempFile(String, String)} when you wish to
   * create a directory, not a regular file. A common pitfall is to call {@code createTempFile},
   * delete the file and create a directory in its place, but this leads a race condition which can
   * be exploited to create security vulnerabilities, especially when executable files are to be
   * written into the directory.
   *
   * <p>This method assumes that the temporary volume is writable, has free inodes and free blocks,
   * and that it will not be called thousands of times per second.
   *
   * @return the newly-created directory
   * @throws IllegalStateException if the directory could not be created
   */
  public static File createTempDir() {
    File baseDir = new File(System.getProperty("java.io.tmpdir"));
    String baseName = System.currentTimeMillis() + "-";

    for (int counter = 0; counter < TEMP_DIR_ATTEMPTS; counter++) {
      File tempDir = new File(baseDir, baseName + counter);
      if (tempDir.mkdir()) {
        return tempDir;
      }
    }
    throw new IllegalStateException(
        "Failed to create directory within "
            + TEMP_DIR_ATTEMPTS
            + " attempts (tried "
            + baseName
            + "0 to "
            + baseName
            + (TEMP_DIR_ATTEMPTS - 1)
            + ')');
  }

Mam ten sam problem, więc jest to kolejna odpowiedź dla zainteresowanych i jest podobna do jednej z powyższych:

public static final String tempDir = System.getProperty("java.io.tmpdir")+"tmp"+System.nanoTime();
static {
    File f = new File(tempDir);
    if(!f.exists())
        f.mkdir();
}

W przypadku mojej aplikacji zdecydowałem, że dodam opcję wyczyszczenia temp przy wyjściu, więc dodałem hak zamykający:

Runtime.getRuntime().addShutdownHook(new Thread() {
        @Override
        public void run() {
            //stackless deletion
            String root = MainWindow.tempDir;
            Stack<String> dirStack = new Stack<String>();
            dirStack.push(root);
            while(!dirStack.empty()) {
                String dir = dirStack.pop();
                File f = new File(dir);
                if(f.listFiles().length==0)
                    f.delete();
                else {
                    dirStack.push(dir);
                    for(File ff: f.listFiles()) {
                        if(ff.isFile())
                            ff.delete();
                        else if(ff.isDirectory())
                            dirStack.push(ff.getPath());
                    }
                }
            }
        }
    });

Metoda usuwa wszystkie podkatalogi i pliki przed usunięciem temp , bez użycia stosu wywołań (który jest całkowicie opcjonalny i w tym momencie można to zrobić z rekurencją), ale chcę być po bezpiecznej stronie.

Jak widać w innych odpowiedziach, nie pojawiło się żadne standardowe podejście. Dlatego wspomniałeś już o Apache Commons, proponuję następujące podejście przy użyciu FileUtils z Apache Commons IO :

/**
 * Creates a temporary subdirectory in the standard temporary directory.
 * This will be automatically deleted upon exit.
 * 
 * @param prefix
 *            the prefix used to create the directory, completed by a
 *            current timestamp. Use for instance your application's name
 * @return the directory
 */
public static File createTempDirectory(String prefix) {

    final File tmp = new File(FileUtils.getTempDirectory().getAbsolutePath()
            + "/" + prefix + System.currentTimeMillis());
    tmp.mkdir();
    Runtime.getRuntime().addShutdownHook(new Thread() {

        @Override
        public void run() {

            try {
                FileUtils.deleteDirectory(tmp);
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    });
    return tmp;

}

Jest to preferowane, ponieważ apache używa biblioteki, która jest jak najbliżej zadanego „standardu” i działa zarówno z JDK 7, jak i starszymi wersjami. Zwraca również „starą” instancję pliku (która jest oparta na strumieniu), a nie „nową” instancję ścieżki (która jest oparta na buforze i byłaby wynikiem metody getTemporaryDirectory () JDK7) -> Dlatego zwraca to, czego potrzebuje większość ludzi, gdy chcą utworzyć katalog tymczasowy.

Lubię wiele prób stworzenia unikalnej nazwy, ale nawet to rozwiązanie nie wyklucza warunków wyścigu. Kolejny proces może wślizgnąć się po teście exists()i if(newTempDir.mkdirs())wywołaniu metody. Nie mam pojęcia, jak całkowicie uczynić to bezpiecznym bez uciekania się do natywnego kodu, który, jak przypuszczam, jest ukryty w środku File.createTempFile().

Przed wersją Java 7 można również:

File folder = File.createTempFile("testFileUtils", ""); // no suffix
folder.delete();
folder.mkdirs();
folder.deleteOnExit();

Spróbuj tego małego przykładu:

Kod:

try {
    Path tmpDir = Files.createTempDirectory("tmpDir");
    System.out.println(tmpDir.toString());
    Files.delete(tmpDir);
} catch (IOException e) {
    e.printStackTrace();
}

Importuje:
java.io.IOException
java.nio.file.Files
java.nio.file.Path

Dane wyjściowe konsoli na komputerze z systemem Windows:
C: \ Users \ nazwa_użytkownika \ AppData \ Local \ Temp \ tmpDir2908538301081367877

Komentarz:
Files.createTempDirectory generuje unikatowy identyfikator atomatycznie - 2908538301081367877.

Uwaga:
Przeczytaj rekursywnie następujące katalogi:
Usuń katalogi rekurencyjnie w Javie

Używanie File#createTempFilei deletedo tworzenia unikalnej nazwy katalogu wydaje się być w porządku. Należy dodać a, ShutdownHookaby usunąć katalog (rekurencyjnie) podczas zamykania JVM.