S
Spacerat
Gast
Hallo...
Hab' grad' 'ne schlimme Erfahrung gemacht... Wunder das es so etwas noch gibt.
Also. Wie oft programmiert man als Entwickler "Rekursivitäten" und wie oft schleichen sich dort Fehler ein. Bei mir hat sich so ein Fehler beim erstellen von Verzeichnissen auf dem NTFS-System eingeschlichen, worauf die Anwendung fröhlich bis zum "Stack-Overflow" Verzeichnisse in immer tiefere Ebenen erstellte.
"Teil A" simuliert hier nur das, was meine Rekursiv-Methode gemacht hat (mit dem Unterschied, das es hier keinen Stack-Overflow gibt?).
Nun kann man ab einer gewissen Verzeichnistiefe bzw. der daraus resultierenden Dateinamenlänge mal versuchen die erstellten Verzeichnisse im Explorer zu löschen. Das wird misslingen. Ebenso scheint das für NTFS auch kein Fehler zu sein, denn CHKDSK behebt das Problem genauso wenig.
Wenn man auf Andere Tools keinen Zugriff hat, lässt sich das Prolem glücklicherweise mit "Teil B" wieder beheben.
Letztenendes frage ich mich nun, ob man das Problem nicht als Bug in der JRE bezeichnen muss, da sie ja für NTFS diese langen Dateinamen zulässt, während NTFS das selber nicht tut. Oder ob es am NTFS-System liegt, das überlange Dateinamen zwar beim schreiben jedoch nicht beim lesen verwendet werden dürfen. Wenn das Zweite zutrifft, wie bekommt die JRE durch Ausführung von "Teil B" diese Dateien wieder weg?
Irgendwas ist da jedenfalls nicht in Ordnung
mfg Spacerat
Hab' grad' 'ne schlimme Erfahrung gemacht... Wunder das es so etwas noch gibt.
Also. Wie oft programmiert man als Entwickler "Rekursivitäten" und wie oft schleichen sich dort Fehler ein. Bei mir hat sich so ein Fehler beim erstellen von Verzeichnissen auf dem NTFS-System eingeschlichen, worauf die Anwendung fröhlich bis zum "Stack-Overflow" Verzeichnisse in immer tiefere Ebenen erstellte.
Code:
// Vorbereitungen
String dir = "\\directory";
File ff = new File("C:" + dir + dir), gg = new File("C:\\scratch"), zz = new File("C:" + dir);
boolean chk = false;
// Teil A Simulation der Rekursivität
while(!chk) {
new File(ff.getAbsolutePath() + dir).mkdirs();
}
// Teil B So bekommt man es wieder weg.
while(ff.exists()) {
if(ff.isDirectory()) {
chk = ff.renameTo(gg);
chk = zz.delete();
chk = gg.renameTo(zz);
}
}Nun kann man ab einer gewissen Verzeichnistiefe bzw. der daraus resultierenden Dateinamenlänge mal versuchen die erstellten Verzeichnisse im Explorer zu löschen. Das wird misslingen. Ebenso scheint das für NTFS auch kein Fehler zu sein, denn CHKDSK behebt das Problem genauso wenig.
Wenn man auf Andere Tools keinen Zugriff hat, lässt sich das Prolem glücklicherweise mit "Teil B" wieder beheben.
Letztenendes frage ich mich nun, ob man das Problem nicht als Bug in der JRE bezeichnen muss, da sie ja für NTFS diese langen Dateinamen zulässt, während NTFS das selber nicht tut. Oder ob es am NTFS-System liegt, das überlange Dateinamen zwar beim schreiben jedoch nicht beim lesen verwendet werden dürfen. Wenn das Zweite zutrifft, wie bekommt die JRE durch Ausführung von "Teil B" diese Dateien wieder weg?
Irgendwas ist da jedenfalls nicht in Ordnung
mfg Spacerat
