# Vorsicht beim Dateisystem NTFS



## Spacerat (24. Dez 2008)

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.

```
// 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);
  }
}
```
"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


----------



## musiKk (24. Dez 2008)

Es ist nicht die Aufgabe der JRE auf Unzulänglichkeiten systemnaher Software zu reagieren. Es gibt Syscalls vom Betriebssystem zum Erzugen, Löschen, ... von Dateien und Verzeichnissen. Wenn so einer fehlschlägt, kommt ein entsprechender Fehler. Der Java-Programmierer sieht das dann meist als IOException. Wenn dieses vom Betriebssystem bereitgestellte Interface inkonsistent ist, dann liegt der Fehler auch dort.


----------



## maki (24. Dez 2008)

>> Vorsicht beim Betriebssystem Windows

So stimmt's


----------



## musiKk (24. Dez 2008)

maki hat gesagt.:
			
		

> >> Vorsicht beim Betriebssystem Windows


Hoffentlich kommt trotz der weihnachtlichen Harmonie noch ein ordentlicher Flamewar zustande.


----------



## maki (24. Dez 2008)

Naja, "Weihnachtsharmonie" ist ein Oxymoron 
Mal ehrlich, die schönsten streitereien gibt es doch zu dieser Zeit des Jahres *g*
Was aber nicht heissen soll ich wollte hier die alte Diskussion (Windows vs. Linux vs MacOSX vs. NetBSD vs. Solaris vs. .... ) wieder aufwärmen


----------



## Spacerat (24. Dez 2008)

maki hat gesagt.:
			
		

> >> Vorsicht beim Betriebssystem Windows
> 
> So stimmt's


Hast ja recht...



			
				maki hat gesagt.:
			
		

> Naja, "Weihnachtsharmonie" ist ein Oxymoron


Was zum... ist ein Oxymoron? Die Frage muss mir hoffentlich nicht peinlich sein...

Frohes Fest... Spacerat


----------



## Bernie (30. Jul 2010)

Spacerat hat gesagt.:


> 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.
> 
> 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.



Ich hoffe ich werde nicht gevierteilt so einen alten Thread zu beantworten.

Der Fehler liegt nicht in NTFS oder im JRE. Der Fehler liegt im Windows-Explorer. Dieser kann nicht alle Möglichkeiten von NTFS und benimmt sich teilweise komisch wenn Dateien/Verzeichnisse kommen die er so nicht selbst anlegen lassen würde (z.B. auch Dateien von SVN welche .svn heißen). Pfade unter Windows dürfen bis 32,767 Zeichen lang sein wenn man auf die WideString/Unicode-Version der API zugreift. Ansonste nur 255 Zeichen relativ zum aktuellen Pfad der Anwendung (Altkompatibliät Win9x/ME)


----------

