Can't delete folder created by junit TemporaryFolderRule

I have a class that manages the archive of some files that we do some incoming processing on. When trying to test the archiving process I made use of the TemporaryFolder rule in JUnit.

On our normal Linux development stations the test runs without any problems, on some Windows laptops some of the team members have, but on my Mac I end up getting the following:

whenFullExtractReceivedArchivesArePurged(housekeeping.ArchiveHousekeeperIntegrationTest): Failed to delete /var/folders/Pl/PlAbV+EpHhW2-nPFrFrwI++++TI/-Tmp-/junit5525189319546810170/secondaryArchive

Here is the test:

package housekeeping;

import static housekeeping.ArchiveHousekeeper.PRIMARY_ARCHIVE;
import static housekeeping.ArchiveHousekeeper.SECONDARY_ARCHIVE;
import static org.hamcrest.Matchers.is;
import static org.hamcrest.Matchers.not;
import static org.junit.Assert.assertThat;

import java.io.File;
import java.io.IOException;
import java.util.Arrays;

import org.hamcrest.Description;
import org.hamcrest.Factory;
import org.hamcrest.Matcher;
import org.hamcrest.TypeSafeMatcher;
import org.junit.Before;
import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.TemporaryFolder;

public class ArchiveHousekeeperIntegrationTest {

  private static final String LANDING_FOLDER = "landing";
  private static final String PREVIOUS_FILE_NAME = "previousChild.txt";
  private static final String CURRENT_FILE_NAME = "currentChild.txt";
  private File primaryArchiveFolder;
  private File secondaryArchiveFolder;
  private File landingFolder;

  @Rule
  public TemporaryFolder temporaryFolder = new TemporaryFolder();

  @Before
  public void setUp() throws IOException {
    temporaryFo开发者_C百科lder.getRoot();
    primaryArchiveFolder = temporaryFolder.newFolder(PRIMARY_ARCHIVE);
    secondaryArchiveFolder = temporaryFolder.newFolder(SECONDARY_ARCHIVE);
    landingFolder = temporaryFolder.newFolder(LANDING_FOLDER);

    createChildFile(primaryArchiveFolder, CURRENT_FILE_NAME);
    createChildFile(secondaryArchiveFolder, PREVIOUS_FILE_NAME);
  }

  @Test
  public void whenFullExtractReceivedArchivesArePurged() throws IOException {
    final String extractFileName = "fullExtract0101.zip";
    final File extractFile = new File(landingFolder, extractFileName);
    extractFile.createNewFile();
    final ArchiveHousekeeper housekeeper = new ArchiveHousekeeper(extractFile);

    housekeeper.archiveFile();

    assertThat(landingFolder.list().length, is(0));
    assertThat(primaryArchiveFolder, containsFile(extractFileName));
    assertThat(secondaryArchiveFolder, not(containsFile(PREVIOUS_FILE_NAME)));
    assertThat(secondaryArchiveFolder, containsFile(CURRENT_FILE_NAME));
    assertThat(primaryArchiveFolder, not(containsFile(CURRENT_FILE_NAME)));
  }

  @Factory
  private static Matcher<File> containsFile(final String fileName) {
    return new TypeSafeMatcher<File>() {

      @Override
      public void describeTo(final Description description) {
        description.appendText("a directory containing " + fileName);
      }

      @Override
      public boolean matchesSafely(final File item) {
        return item != null && item.isDirectory() && Arrays.asList(item.list()).contains(fileName);
      }
    };
  }

  private File createChildFile(final File parent, final String child) throws IOException {
    final File folder = new File(parent, child);
    folder.createNewFile();
    return folder;
  }
}

I am not sure if I am seeing some sort of odd permission issue or what, that is what it seems like. I just find that perplexing as the test creates the folder so it seems like it should have permissions on it.

It is worth noting that the code under test does seem to work, on other platforms the test runs successfully.

---

As it turns out, there wasn't enough detail in the original question. The ArchiveHousekeeper was using Files.recursivelyDelete from Guava.

That particular implementation of file delete has some protections to stop the deletion of symlinks. The way TemporaryFolder works on a Mac creates a symlink and it won't delete the contents of the secondary archive so the deletion of the actual folder fails. Leading to the exception being thrown.