Dateien werden nicht gelöscht - warum?

Diskutiere Dateien werden nicht gelöscht - warum? im Allgemeine Java-Themen Bereich.
Bitte aktiviere JavaScript!
W

White_Fox

Guten Abend allerseits

Ich habe hier einen Unittest, für den ein paar Dateien erstellt werden müssen.

Java:
public class CLSFileDocumentTest {
    static File testTrackDirectory;
    
    public CLSFileDocumentTest() {
    }
    
    @BeforeClass
    public static void setUpClass() {
    }
    
    @AfterClass
    public static void tearDownClass() {
    }
    
    @Before
    public void setUp() {
        testTrackDirectory = new File("TestTrack");
        testTrackDirectory.mkdir();
    }
    
    @After
    public void tearDown() throws IOException {
        for(File f : testTrackDirectory.listFiles()){
            //System.out.println("Lösche Datei: " + f.getName() + ": " + f.deleteOnExit());
            f.delete();
        }
        testTrackDirectory.delete();
    }
    
    class CLSFileDocumentImplementation extends CLSFileDocument<LibraryRoot>{

        public CLSFileDocumentImplementation(LibraryRoot object) {
            super(object);
        }

        public CLSFileDocumentImplementation(String path) {
            super(path);
        }
        
        @Override
        protected FileTypes getFileType() {
            return FileTypes.LIBRARY;
        }
    }

    /**
     * Test of saveAs method, of class CLSFileDocument.
     */
    @Test
    public void testSaveAs() {
        CLSFileDocument instance;
        String path;
        File f;
        
        System.out.println("saveAs");
        
        path = testTrackDirectory.getAbsolutePath() + File.separator +
                "SaveAs-Test";
        instance = new CLSFileDocumentImplementation(new LibraryRoot("SaveAs-Test Library"));
        instance.saveAs(path);
        
        path = path + FileTypes.LIBRARY.suffix();
        f = new File(path);
        assertTrue(f.exists());
    }
}
Es soll ein Verzeichnis angelegt werden, in diesem sich die zu testende Klasse austoben kann. Danach soll das Verzeichnis wieder gelöscht werden, aber das wird es nicht. Weiß jemand, woran das liegen könnte?
 
T

TM69

Auf welcher Partition erstellst du das Verzeichnis? Auf C: könnte es aus Sicherheitsbedingungen von Windows sein, dass du kein Verzeichnis erstellen kannst. Und wenn du kein Verzeichnis erstellt hast kann es nicht gelöscht werden, bzw. wenn du per Hand ein Directory erstellst du aus Sicherheitsgründen dieses nicht löschen kannst.

Es kann aber auch sein, dass das Verzeichnis nicht leer ist. Verwende aus z.B. org.apache.commons.io.FileUtils.deleteDirectory die rekursiv, einschließlich der beinhalteten Verzeichnisse und Dateien löscht.
 
Zuletzt bearbeitet:
W

White_Fox

@TM69 Das Erstellen des Verzeichnisses klappt (aktuell liegt der Ordner irgendwo im Benutzerordner).
Nur das Löschen geht nicht. Die erste Datei wird gelöscht, aber alle anderen nicht. Ich hab mir mal das Ergebnis der delete-Methode auf der Konsole ausgeben lassen.

@mihe7 Nein, das ist nur ein Ordner mit ein paar Dateien drin. Unterverzeichnisse werden für den Test nicht erstelt.
 
W

White_Fox

Oh...tatsächlich.

Ich wollte zuerst schreiben daß die File-Klasse ja keine close()-Methode hat, die hab ich nämlich gesucht. Aber zwei Streams waren noch offen...die habe ich nicht beachtet.
 
J

JustNobody

Oh...tatsächlich.

Ich wollte zuerst schreiben daß die File-Klasse ja keine close()-Methode hat, die hab ich nämlich gesucht. Aber zwei Streams waren noch offen...die habe ich nicht beachtet.
An dieser Stelle möchte ich einfach einmal auf eine Kleinigkeit hinweisen:
Ein Pattern, welches ich immer anwende, ist:
- Alles was Closeable ist (Also auch Deine Streams) werden in try with resource genutzt, so es lokale Variablen sind.
- Ist es keine lokale Variable sondern eine Instanzvariable, dann wird die Klasse selbst Closeable implementieren.
==> Damit wird dann diese Regel wieder auf die Instanz dieser Klasse angewendet werden müssen und das geht dann halt immer weiter bis halt irgendwann eben eine lokale Variable auftaucht ...

Einzige Ausnahmen kann man sich auch schön bildlich vorstellen, denn das sind sozusagen "göttliche" Variablen. Die existieren von "Ewigkeit zu Ewigkeit" und für die gelten so weltliche Regeln natürlich nicht. Aber wie bei allen göttlichen Dingen: Es ist toll, wenn jemand daran glaubt, aber wir wollen doch möglichst wissenschaftlich bleiben und versuchen daher, so göttliche Dinge zu vermeiden....
==> Da sind wir dann bei statischen Dingen. Also sowas wie System.in, System.out, System.err
(Ja, das ist sehr bildlich und nicht ganz korrekt. Denn natürlich existieren statische Variablen nicht von Ewigkeit zu Ewigkeit, sondern es ist wie immer bei so Programmen vollkommen deterministisch und klar definiert, wann was wie erstellt wird. Aber im Rahmen einer einfach zu merkenden Regel wurde dies einfach ignoriert und ich habe mich als "religösen Fanatiker" geoutet :) )
 
W

White_Fox

Junit bietet dafür btw. von Haus aus das passende an (du scheinst noch auf 4 zu sein, für 5 gibts aber was äquivalentes)
HA...das kannte ich noch nicht. Ich arbeite tatsächlich noch mit Version 4. Du hattest ja letzten schonmal einen Hinweis für mich, den ich deswegen leider nicht umsetzen konnte.

Ein Pattern, welches ich immer anwende, ist:
- Alles was Closeable ist (Also auch Deine Streams) werden in try with resource genutzt, so es lokale Variablen sind.
- Ist es keine lokale Variable sondern eine Instanzvariable, dann wird die Klasse selbst Closeable implementieren.
Richtig, try und finally...warum bin ich da nicht schon von alleine drauf gekommen? So mache ich das.
 
M

mrBrown

Ich arbeite tatsächlich noch mit Version 4.Du hattest ja letzten schonmal einen Hinweis für mich, den ich deswegen leider nicht umsetzen konnte.
Gibts denn eigentlich nen Grund für JUnit 4?

Hierbei gehts zwar genausogut mit 4 wie mit 5, 5 ist aber schon ne Ecke netter.


Richtig, try und finally...warum bin ich da nicht schon von alleine drauf gekommen? So mache ich das.
Wobei du finally eigentlich nie selbst brauchst, wenn du try-with-resources nimmst ;)
 
W

White_Fox

M

mrBrown

Gegenfrage: was spricht gegen JUnit 4 oder für JUnit 5?
Mir persönlich gefällt die API deutlich besser, sowohl von den Namen als auch der Benutzbarkeit her. zb die Benennung mit @BeforeAll/@BeforeEach statt @BeforeClass/@Before oder das Schachteln von Tests (vorher mit nem extra Runner, mit dem manches nicht ging, jetzt ganz normal mit inneren Klassen.)

Dann finde ich das Extension-Model schöner/praktischer, als das alte mit Rules und Runnern, Parametrizierte Tests sind auch super einfach - fühlt sich einfach alles irgendwie "runder" an
 
Thema: 

Dateien werden nicht gelöscht - warum?

Passende Stellenanzeigen aus deiner Region:
Anzeige

Neue Themen

Anzeige

Anzeige
Oben