Dateihandling Zeiger auf nächste Datei?

[Marc T.]

Hallo Leute,

gibt es in Java einen mechanismus, mit dem ich aus einem Ordner
Datei für Datei auslesen kann? Also so etwas wie ein Zeiger auf die
nächste Datei.

Ich muss jede Datei aus einem Verzeichnis bearbeiten, dass sind allerdings
so viele Dateien, dass ich sie unmöglich mit java.io.File.listFiles() zwischen-
speichern kann.

Ich darf die Dateien nach dem bearbeiten nicht löschen und auch nicht
verschieben.

Kennt da jemand was?

 

[Network]

Also es ist mir nichts bekannt wie das gehen könnte.
Wenn du listFiles ausführst wird die Methode list() des Objektes der Klasse FileSystem ausgeführt. Wenn ich mich nicht verlesen habe, aber Eclipse scheint die Klasse FileSystem nicht zu kennen und der Oracle Documentation zufolge enthält diese nicht die Methode list();

Ich muss mich verlesen haben. Aber schau dir dochmal den SourceCode der Klasse File an, und rückverfolge die aufgerufenen Methoden und Klassen.
Evt. stolperst du ja irgendwann über eine Klasse oder einen Codeabschnitt der exakt das kann/macht, was du im Moment brauchen könntest

Gruß
Net

 

[andreT]

... dass sind allerdings
so viele Dateien, dass ich sie unmöglich mit java.io.File.listFiles() zwischen-
speichern kann.

Darf ich mal fragen wieviel Dateien konkret da z.B. in einem Verzeichnis rumliegen?

 

[nillehammer]

dass ich sie unmöglich mit java.io.File.listFiles() zwischen-
speichern kann.

Hä? Wieso zwischenspeichern? Wenn Du die Methode auf einem File-Object aufrufst, das ein Verzeichnis repräsentiert, bekommst Du doch einfach ein Array mit allen im Verzeichnis liegenden Dateien? Das kannst Du doch dann durchiterieren. Falls die Erzeugung so vieler File-Objects zu Speicherproblemen führt (was ich mir kaum vorstellen kann), kannst Du entweder Xmax raufsetzen, einen Filter bauen, der Teilmengen extrahiert oder auf die list-Methoden (ohne das "Files" am Ende)umsteigen. Die geben Dir Strings zurück. Ein String verbraucht möglicherweise weniger Speicher als ein File-Object.

 

[Marc T.]

... Wenn Du die Methode auf einem File-Object aufrufst, das ein Verzeichnis repräsentiert, bekommst Du doch einfach ein Array mit allen im Verzeichnis liegenden Dateien? Das kannst Du doch dann durchiterieren. Falls die Erzeugung so vieler File-Objects zu Speicherproblemen führt (was ich mir kaum vorstellen kann), kannst Du entweder Xmax raufsetzen, einen Filter bauen, der Teilmengen extrahiert oder auf die list-Methoden (ohne das "Files" am Ende)umsteigen. Die geben Dir Strings zurück. Ein String verbraucht möglicherweise weniger Speicher als ein File-Object.

Jo aber diese Liste mit Files werden im Speicher der virtuellen Maschine "zwischen gespeichert"
Es handelt sich um mindestens 200.000 Dateien die eingelesen und verarbeitet werden müssen.
Und ja der Overhead ist da. Habe der JVM schon 4 GB gegeben und es gibt einen schönen
"outOfMemoryError".

Das mit den Teilmengen hatte ich mir gedacht.... allerdings darf ich die Grundmenge (also die
Dateien im Ordner) auf keinen Fall verändern oder verschieben, weshalb ich mir ja dann
irgendwie merken müsste, welche Dateien ich schon hatte und welche nicht.
Das Programm hat sowieso schon nen mordsmäßigen Ressourcenverbrauch (sowohl Speicher,
als auch CPU).

Hat Java für so etwas keine Lösung? oO Hab mir die File Klasse und das was dran hängt mal
angeschaut und konnte nichts finden......

 

[andreT]

200.000 Dateien in einem Ordner?

 

[Mujahiddin]

Wie wär's mit folgendem:

private void processOverFiles(final Path p) {
	try {
		Files.walkFileTree( p, new SimpleFileVisitor<Path>() {
			
			@Override
			public FileVisitResult visitFile(final Path file, final BasicFileAttributes bfa) {
				doSomethingWith( file ); // hier kommt dein Code rein!
				return FileVisitResult.CONTINUE;
			}
		} );
	} catch( IOException e ) {
		e.printStackTrace();
	}
}

private void processOverFiles(final File f) {
	processOverFiles( f.toPath() );
}

 

[nillehammer]

Das mit den Teilmengen hatte ich mir gedacht.... allerdings darf ich die Grundmenge (also die
Dateien im Ordner) auf keinen Fall verändern oder verschieben, weshalb ich mir ja dann
irgendwie merken müsste, welche Dateien ich schon hatte und welche nicht.

Könnte man mit einem FileNameFilter machen, der jeweils nach Anfangsbuchstaben filtert.

Ich denke aber, dass Mujahiddin's Lösung die eleganteste ist.

 

[Marc T.]

Wie wär's mit folgendem:

private void processOverFiles(final Path p) {
	try {
		Files.walkFileTree( p, new SimpleFileVisitor<Path>() {
			
			@Override
			public FileVisitResult visitFile(final Path file, final BasicFileAttributes bfa) {
				doSomethingWith( file ); // hier kommt dein Code rein!
				return FileVisitResult.CONTINUE;
			}
		} );
	} catch( IOException e ) {
		e.printStackTrace();
	}
}

private void processOverFiles(final File f) {
	processOverFiles( f.toPath() );
}

Ich verstehe nicht was hier genau getan wird.

Übergibt man an diese Methode den Pfad zum Ordner und der iteriert alle Files?
Und handelt diese ab?
Wenn ja, werden nicht alle Dateien dann irgendwo im Speicher abgelegt?
Lässt sich dieses walkFileTree auch parallelisieren?

 

[dranrumbastler]

Jo aber diese Liste mit Files werden im Speicher der virtuellen Maschine "zwischen gespeichert"
Es handelt sich um mindestens 200.000 Dateien die eingelesen und verarbeitet werden müssen.
Und ja der Overhead ist da. Habe der JVM schon 4 GB gegeben und es gibt einen schönen
"outOfMemoryError".

Das mit den Teilmengen hatte ich mir gedacht.... allerdings darf ich die Grundmenge (also die
Dateien im Ordner) auf keinen Fall verändern oder verschieben, weshalb ich mir ja dann
irgendwie merken müsste, welche Dateien ich schon hatte und welche nicht.
Das Programm hat sowieso schon nen mordsmäßigen Ressourcenverbrauch (sowohl Speicher,
als auch CPU).

Hat Java für so etwas keine Lösung? oO Hab mir die File Klasse und das was dran hängt mal
angeschaut und konnte nichts finden......

Das ist schon mal die komplett falsche Idee. Grundsätzlich "speicherst" du nur die File-Objekte "im RAM". Alle Files einlesen und im RAM halten ist der falsche ansatz. Du solltest immer nur das File im RAM haben was du auch gerade wirklich bearbeitest und das Ergebnis am besten auch wieder in ein File rausschreiben und den RAM aufräumen, oder bearbeitest du ALLE 200k Files auch wirklich GLEICHZEITIG ?. 200k File-Objekte werden schon was belegen ... man kanns auch noch mit String-Objekten machen und nur den Namen auf das File halten und dann jedes mal daraus ein neues File-Objekt bauen ... aber ob das so sinnvoll ist ? Müsste man ausprobieren.

Also : File.list() bzw File.listFiles() und nur dieses Array im RAM halten. Beim drüber-iterieren jeweils das File laden, verarbeiten, Ergebnis in ein anderes File rausschreiben und RAM aufräumen. Das sollte dann selbst mit den standard-Werte (glaube 64MB oder 128MB Heap) laufen.
Wenn du dann mit den Ergebnissen noch was machen musst dann gehst du dabei genau so vor : wieder Referenz-Array bauen (vorher das andere aufräumen !) und durchgehen und Ergebnis in entsprechenden Output umleiten. Natürlich dauert das auf Grund der lahmen Platte länger als wenn du alles komplett im RAM halten würdest, aber da das nicht geht musst du halt auf Platte cachen, und das macht man in dem man den Inhalt eines Objektes in ein File rausschreibt und dann ausm RAM nimmt.

 

[Marc T.]

Also : File.list() bzw File.listFiles() und nur dieses Array im RAM halten. Beim drüber-iterieren jeweils das File laden, verarbeiten, Ergebnis in ein anderes File rausschreiben und RAM aufräumen. Das sollte dann selbst mit den standard-Werte (glaube 64MB oder 128MB Heap) laufen.
Wenn du dann mit den Ergebnissen noch was machen musst dann gehst du dabei genau so vor : wieder Referenz-Array bauen (vorher das andere aufräumen !) und durchgehen und Ergebnis in entsprechenden Output umleiten. Natürlich dauert das auf Grund der lahmen Platte länger als wenn du alles komplett im RAM halten würdest, aber da das nicht geht musst du halt auf Platte cachen, und das macht man in dem man den Inhalt eines Objektes in ein File rausschreibt und dann ausm RAM nimmt.

Darum gings ja genau, dass ich nicht denke, dass es funktioniert alles im RAM zu halten.

Aber mit listFiles() erzeuge ich doch ein Array von Files und habe somit alle 200.000 Dateien
im Speicher stehen.....

 

[Michael...]

Darum gings ja genau, dass ich nicht denke, dass es funktioniert alles im RAM zu halten.

Aber mit listFiles() erzeuge ich doch ein Array von Files und habe somit alle 200.000 Dateien
im Speicher stehen.....

Es werden aber sicherlich nicht 200.000 Dateien in einem Verzeichnis stehen? (Abgesehen davon, dass dann ein Array mit 200.000 File Objekten - nicht Dateien - im Speicher stehen würden)
Einfach sich rekursiv durch die Verzeichnisse arbeiten. Gefundenen Dateien wie gewünscht bearbeiten und gefundene Verzeichnis wiederum rekursiv bearbeiten. Dann hat man maximal soviele File Objekte im Speicher wie Dateien und Unterverzeichnisse (+x) in dem Verzeichnis enthalten sind. Wichtig wäre, dass man zuerst alle Dateien eines Verzeichnisses abarbeitet bevor man beginnt sich rekursiv durch die Unterverzeichnisse zu arbeiten. Problematisch könnte auch ein zu große Verzeichnistiefe werden - aber das müssten einige ungünstige Faktoren zusammen kommen.

 

[Marc T.]

... aber genau so ist es.... ich sagte sogar mind. 200.000 Dateien!
Es werden jeden Tag ca. 30.000 Dateien mehr
Und die stehen alle in einem Verzeichnis. Und genau das ist mein Problem.
Ich kann keine Java-Struktur finden, die es mir erlaubt über alle Dateien
zu iterieren ohne mir alle Dateien als Files ins Programm zu holen.....

 

[andreT]

... aber genau so ist es.... ich sagte sogar mind. 200.000 Dateien!
Es werden jeden Tag ca. 30.000 Dateien mehr
Und die stehen alle in einem Verzeichnis. Und genau das ist mein Problem.
Ich kann keine Java-Struktur finden, die es mir erlaubt über alle Dateien
zu iterieren ohne mir alle Dateien als Files ins Programm zu holen.....

Keine Ahnung was du da programmierst, aber 1.000.000 Filereferenzen machen bei mir ca. 28-30 MB aus. Zeig doch mal deinen Quelltext, ich vermute da hapert es an ... was auch immer

 

[Mujahiddin]

Die Methode

Files.walkFileTree

erzeugt einen neuen DirectoryStream und iteriert über alle Einträge in dieser Directory.

Ob alle Einträge irgendwo gespeichert werden, oder das Programm die Einträge nacheinander bezieht, weiß ich nicht. Wieso probierst du es nicht einfach. Wenn eine OutOfMemoryError geschmissen wird, weißt du Bescheid.

Ich weiß nicht, ob man das Parallelisieren kann.
Du könntest eventuell mit Files.newDirectoryStream(path).iterator() den iterator aufrufen und dort parallele Zugriffe ermöglichen. Du müsstest das ganze synchronisieren.



Übrigens hab ich gerade etwas probiert: Während des Iterierens eine neue Datei erstellt in dem iterierten Ordner, und diese neue Datei war nicht drin. Also werden anscheinend alle Dateien irgendwo zwischengespeichert.

Da scheint es wohl keinen Weg drumrum zu geben als deiner JVM mehr Speicher zu geben. Mit Stringreferenzen könntest du viel Speicher sparen und dann mit "path.resolve(myStrings[x])" auf den Pfad zugreifen bzw via

new File(directory, myStrings[x])

 

[Michael...]

200.000 Dateien auf einer Ebene in einem Verzeichnis? Macht da das OS noch mit?
Mit den Java 1.7 Klassen kenne ich mich nicht aus. Aber schon mal File#list() ausprobiert? Die Methode liefert ja nur eine Array mit den Dateinamen, sollte weniger speicherintensiv sein als ein File Array.

 

[Marc T.]

Nene, ich habe diesen Part noch nicht programmiert. Es ging erstmal um die Theorie,
weil man ja vorher denken sollte bevor man los programmiert
Ich dachte mir nur, dass es unglaublich viel Speicher kosten würde, aber wenn du sagst,
dass es nur so wenig ist, scheint es kein Problem zu sein.

Das OS machts mit jo.

Ich werde das mal ausprobieren mir einfach nur die Dateinamen als Strings zu packen.
Danke euch

 

[Mujahiddin]

Jo aber diese Liste mit Files werden im Speicher der virtuellen Maschine "zwischen gespeichert"
Es handelt sich um mindestens 200.000 Dateien die eingelesen und verarbeitet werden müssen.
Und ja der Overhead ist da. Habe der JVM schon 4 GB gegeben und es gibt einen schönen
"outOfMemoryError".

Habe der JVM schon 4 GB gegeben und es gibt einen schönen "outOfMemoryError".

Habe

Was bringt es, Sachen zu behaupten, die nicht mal stimmen? Wirklich eigenartig.


Übrigens würde ich dir raten, es zuerst mit Files.walkFileTree zu versuchen. Falls das nicht klappt, auf die String-Variante zugreifen.

 

[andreT]

Was bringt es, Sachen zu behaupten, die nicht mal stimmen? Wirklich eigenartig.

Somit ist klar warum er auf meine ersten beiden Fragen nicht geantwortet hat

Übrigens würde ich dir raten, es zuerst mit Files.walkFileTree zu versuchen. Falls das nicht klappt, auf die String-Variante zugreifen.

Werde ich hier eigtl. ignoriert?
1 Mio. ...

 

[Mujahiddin]

Ja, vor allem, 4 GB und immer noch outOfMemoryError. Ich weiß ja wirklich nicht, was er davon hat, wenn er solche Märchengeschichten erzählt. 200.000 Strings nehmen maximal!! 50 MB in Anspruch, wenn ein String 70 Bytes in Anspruch nimmt... (Und ein String mit 14 Zeichen nimmt ca. 70 Bytes in Anspruch.)
70*200000 = 13 MB
Heißt, 400000 Dateien sind 26 MB
sind die Strings 28 Zeichen lang, sind das 52 MB. Das ist gar nix.

 

[nillehammer]

Ich habe mir mal den Quellcode von File und von String angeschaut, um grob einschätzen zu können, wieviel Speicher Instanzen dieser Klassen verbrauchen. Das ist alles super wenig. Man spart auch durch den Umstieg von File auf String nicht wirklich was. Den größten Anteil hat hier der char[]-Array im String (der wiederuum eine Instanzvariable in File ist). Wenn Du nicht gerade super lange Pfadnamen hast, dürfte aber auch das nicht viel sein.

Wenn wir großzügig schätzen, dass eine Instanz 1KB Speicher verbraucht, wären das bei 200.000 Files 200.000KB = 200MB. Alleine das Auflisten dürfte also nicht zu einem OutOfMemoryError führen, wenn Du 4GB Heap spendierst.

Entweder irgend eine Deiner Aussagen ist tatsächlich nicht richtig oder Du hast an ganz anderer Stelle einen Speicherfresser eingebaut.

Wie dem auch sei, ich denke hier sind genug Ansätze genannt, mit denen Du weiterarbeiten kannst. Höre also auf zu "denken" und implementier mal was und probiere es aus. Wenn es dann konkrete Probleme gibt, neuer Thread neues Glück.

P.S. Und an den Gotteskrieger ein Danke für den Tipp mit Files.walkTree. Ich muss mich echt mal mehr mit den neuen Funktionen von Java 7 beschäftigen... ich hätte nämlich selbst einen Algorithmus zum durchlaufen des Verzeichnisbaumes geschrieben :autsch:

[EDIT]Ja, da war ich mit meiner Berechnung zu langsam und wohl auch etwas zu großzügig [/EDIT]

 

[Mujahiddin]

[OT]Mujahiddin heißt wörtlich übersetzt 'Die sich anstrengen', also Mehrzahl, allerdings hatte ich das seinerzeit mit 'Mujahid-ud-din' verwechselt, was heißen würde 'Der sich für seinen Glauben anstrengt'. Gotteskrieger kann man auch sagen, aber der Begriff wird oft fehlinterpretiert (wurde in manchen Foren sogar gesperrt wegen Verstoß gegen irgendwelche Verfassungsrichtlinien :autsch[/OT]

 

[Marc T.]

Zu dem outOfMemoryError:

Einerseits scheint ihr aufmerksame Leser zu sein andererseits aber auch
wieder nicht, denn wie ich bereits geschrieben habe verursacht der Rest
des Programms schon gewaltigen Ressourcenverbrauch.
Allerdings kam der outOfMemoryError erst, als ich das mit dem laden der
Files kurz ausprobiert habe. Es kam also zum Rest dazu.

Wenn man schon alles kleinlich auseinander nimmt, sollte man dann auch
konsequent sein

Des weiteren habe ich auch erwähnt, dass täglich ca. 30.000 Dateien
hinzukommen. Irgendwann ist dann jeder Arbeitsspeicher voll, weswegen
eine Variante zum Iterieren der Dateien an sich immer noch viel besser wäre.

 

[andreT]

Spar dir doch bitte auch die lächerlichen privaten Maßregelungs-Nachrichten a la : "Zu viel Zeit? ..."
Man gibt sich Mühe dir zu helfen, erstens antwortest du auf die Fragen nicht dann stellt sich auch noch heraus daß du offensichtlich vorher gar nicht programmiert hattest. Und dann auch noch dieser unsägliche 4GB Unsinn!
Ich finde Mujahiddin's Kritik VOLLKOMMEN berechtigt und kann diese absolut "unterschreiben"!
Und am Ende sind wir auch noch Schuld weil wir nicht richtig gelesen haben? Alles klar :lol:
Lächerlich!

 

[Marc T.]

Ich bin jetzt nochmal Beitrag für Beitrag durchgegangen und verstehe nicht wo
das Problem liegt und welche Fragen ich nicht beantwortet haben soll.

- Ich hatte gefragt, ob es eine Möglichkeit gibt sich aus einem Verzeichnis
Datei für Datei auszulesen und immer den Zeiger auf die nächste Datei zurück
zu bekommen.
- Ich habe gesagt, dass ich die Dateien in Form von java.io.File nicht alle
auf einmal ins Programm "laden" möchte, da ich einen sehr hohen Ressourcen
verbrauch habe.
- Ich habe gesagt, dass ich das mit dem Einlesen der Dateien noch nicht
aus implementiert habe.
- Ich habe gesagt, dass ich es probiert habe und bei der Verwendung des
Vorschlags, alle Files einzulesen, einen outOfMemoryError bekommen habe,
trotz Zuweisung von 4 GB RAM an die JVM (passiert automatisch über ein
Skript, das hatte ich nicht erwähnt und Ja! Ich verstehe unter aus implementieren
was völlig anderes als "es auszuprobieren".
- Ich hatte erwähnt, dass ich sehr sehr viele Dateien habe und sie von Tag
zu Tag mehr werden, weshalb früher oder später jeder Speicher voll wird.

Die einzige Frage, die ich nicht beantwortet habe ist die, was ich denn
Programmiere. Das allerdings würde den Rahmen für dieses Forum sprengen,
da das ein viel zu kompliziertes und vor allem in der Allgemeinheit unbekanntes
Themengebiet ist, weshalb ich das Problem auf das wesentlich beschränkt habe.

 

[dranrumbastler]

@TO
1) Vielleicht sollte man sich mal überlegen schon das Programm zu ändern das die Dateien anlegt und so implementieren das für jeden Tag ein neuer eigener Unter-Ordner verwendet wird. Damit reduziert man schon mal deutlich die Datenflut. Dann könnte man das ganze noch weiter nach Wochen, Monate und Jahre in weitere Unter-Ordner stecken. Man müsste sich zwar für eine komplette "Verarbeitung" einmal rekursiv durchhanglen (was dann schon am Stack fressen dürfte), aber danach nur noch im festgelegten Intervall mit den bereits vorhandenen Ergebnissen und den neuen Daten weiterarbeiten. Dadurch wird die Last deutlich reduziert.
2) Wie kommst du denn bitte auf die Idee das Java eine Datei komplett in den RAM laden würde nur weil du darauf ein File-Objekt erstellst ? Das ist totaler Unsinn ! Als Beispiel : du legst ein neues File-Objekt auf eine 100MB große Datei an. Frage : wie viel RAM braucht das ? Antwort : weniger als 1kB ! WARUM : ich kenne die genaue Implementierung nicht, aber es werden lediglich Meta-Daten wie Pfad/Name, Größe und sowas im RAM gehalten. Alles andere wird beim Zugriff über native-Methoden jedes mal "on-the-fly" returned, und so lange du darauf keine ewigen Referenzen hälts auch nach dem Block-Ende aufgeräumt in dem es gültig ist. Wenn du jetzt also ein File-Array auf 100 Files hast die jeweils 100MB groß sind, dann hast du im RAM keine 100*100MB = 10TB im RAM sondern lediglich 100*(Speicherverbrauch eines File-Objektes) was dann, wenn man von 1kB pro Objekt ausgeht, gerade mal 100kB sind. Man merkt gerade an genau dieser Aussage das du hier nur ziemlich theoretisch (und das auch noch extrem falsch) unterwegs bist anstatt einfach mal ein einfaches Beispiel zu implementieren was dir zeigen würde das deine Überlegungen schlicht falsch sind. Wenn du ein File in den RAM laden willst brauchst du einen Buffer (meist Byte-Array) und einen InputStream über den du das File liest. So lange du das NICHT machst hast du das File auch nicht im RAM.
3) Du hast Probleme mit dem "seriellen / paralellen Verarbeiten von Daten", denn so wie sich das anhört (Iterator) arbeitest du eh nur mit jeweils EINEM File, und das eins nach dem anderen. Also würde es nicht mal Sinn machen über alle Files in den RAM zu laden (was ja wie bei 2 genannt NICHT der Fall ist) da du eh nicht alles GLEICHZEITIG machst. Wenn man das ganze parallel macht (z.B. weil es für eine Rechnung wichtig ist) würde es schon eher Sinn machen pro Thread die nötige Datei in den RAM zu holen, aber auch wirklich NUR die NOTWENDIGEN Daten. Alles im RAM zu haben macht auch bei 100 CPU-Kernen keinen Sinn wenn man nicht wirklich 100 Threads GLEICHZEITIG rattern lässt. Zu mal das Ergebnis am Ende eh bestimmt wieder nur "seriell" verarbeitet wird. Du machst dir über Probleme gedanken die es so gar nicht gibt.

Wie auch andere gesagt haben : versuche erstmal unsere Antworten zu verstehen und auf unsere Fragen bitte auch zu antworten. Und nimm dir mal bitte ein paar kleine Beispiele zu deinen "Problemen" vor damit du so eine Lösung erarbeiten kannst (oder festestellen kannst das deine Gedanken falsch sind).

Es bringt nichts wenn du uns nach Hilfe fragst wenn du dann unsere Antworten ignorierst / nicht verstehst und auf genauere Nachfragen keine Antwort gibst, weil dann KÖNNEN wir dir einfach NICHT helfen.

Deine Grundfrage war ob es in Java etwas gibt um über Daten in einem Verzeichnis zu iterieren. Die einfachste Antwort : ein File-Objekt auf das Verzeichnis und dann mit File.list() sich ein Array der Files und Sub-Dirs zu besorgen und diese in einem foreach() zu durchlaufen. Und diese Antwort kam, und nicht nur von mir. Deine falsche Annahme, das ein File-Objekt gleich das ganze File in den RAM holen würde lässt dich nun fälschlicherweise vermuten das es daran liegen könnte, obwohl der eigentliche Speicher-Fresser sicherlich ganz wo anders liegt. Und wenn es vor dem Einfügen deines Codes noch lief, dann poste uns doch einfach mal grob, am besten als lauffähiges Beispiel, WAS genau du eingebaut hast was nun nicht mehr läuft. Es gibt hier einige die sicher sofort den wahren Fehler finden würden. Dein Blockade ist gerade nur "falsches Wissen".

 

[Marc T.]

Also auf die Anfangsfrage bezogen: Nein es gibt keine Möglichkeit.

Danke.

 

[X5-599]

Hi,

Du könntest auch mal mit jvisualvm.exe versuchen festzustellen was den OutOfMemory Fehler verursacht. Sollten es tatsächlich die File Objekte sein, müsste man das da gut sehen können.

Ich halte das aber ebenfalls für umwahrscheinlich...

P.S. Das Programm ist Teil des JDK. Zu finden in dessen bin/ Ordner

 

[dranrumbastler]

Also auf die Anfangsfrage bezogen: Nein es gibt keine Möglichkeit.

Danke.

Sorry, aber wenn ich diese Antwort in Zusammenhang zu deiner Topic-Frage setze verstehe ich beide nicht.

Was meinst du überhaupt mit "Pointer der auf das nächste File zeigt" ? Sowas wird es in KEINER Sprache geben denn sowas ist abhängig vom OS und vom File-System der Ziel-Partition ob sowas überhaupt angeboten wird (was mir neu wäre) und wenn ja wie es implementiert ist.

Es mag sein das es Frameworks gibt (egal ob für Java oder andere Sprachen) die dann sowas wie "File.getNextFile()" haben, aber auch darin würde dann wenn überhaupt auf eine List oder ein direkt auf ein Array zugegriffen und lediglich der nächste Eintrag returned werden.

Es würde sich außerdem die Frage stellen was passiert wenn du beim letzten File eines Ordners angekommen bist : gibt nun "nextFile" das nächste Element des Überordners wieder ? Oder wird wieder im selben Ordner von "oben" begonnen ? Und was passiert mit Unter-Ordnern ? Werden diese automatisch "geöffnet" oder nur als Objekt returned auf das man dann selbst wieder "nextFile" anwenden muss ? Und ganz wichtig : iterativ oder rekursiv ?

Du hast echt komische Vorstellungen : einen Pointer auf das nächste File, "new File()" würde das ganze File direkt in den RAM lesen, Speicher-Leaks die durch völlig absurde Konstrukte entstehen würden ...
Erlich, mir gegenüber macht es den Anschein das du nicht mal Probleme mit Java oder Programmieren selbst hast sondern eher viel mehr damit logisch zu begreifen wie ein Rechner überhaupt funktioniert und was theoretisch machbar ist. Du musst dir vor Augen halten das grundsätzlich ALLES was ein Rechner machen soll von jemanden programmiert werden muss. Und wenn es halt die von dir gewünschte Funktion noch nicht gibt, weil sie z.B. so noch keiner brauchte, dann bist eben du derjenige welcher das programmieren muss. Auch wenn es schon recht umfangreiche und mächtige Sprachen gibt kann man nicht verlangen das es DIE EINE gibt in der wirklich alles schon drin ist, denn dann würde bestimmt jeder diese nutzen.

Ich will dich hier nicht persönlich angreifen, aber von deinen Antworten, deinen Vorstellungen, Reaktionen und dem Wissen wie es hier rüber kommt machst du auf mich nun mal leider den Eindruck als hättest du arge Probleme die an sich nicht wirklich was mit Java selbst zu tun haben.

 

[Spacerat]

Die Methode FileWalkTree (oder wie auch immer) sollte zumindest das auschliessen, was bei einer Implementation Marke Eigenbau ziemlich oft und ziemlich schnell zu einer Endlos-Rekursion führt, nämlich ein und dasselbe Verzeichnis immer wieder scannen. Aber dann ist nicht etwa der Heap (4GB) voll, sondern eher der Stack (nach ca. 12500 Rekursionen ist Schluss, bei mir jedenfalls). Allerdings kommt dann in den seltensten Fällen ein OutOfMemoryError (aber es ist möglich), sondern ein StackOverflowError. Möglicherweise reicht ja die Verzeichnistiefe des OS nicht so weit, wie die Rekursionstiefe, weswegen es in diesem Fall halt zu einem OutOfMemoryError führt.

 

[dranrumbastler]

Die Frage ist doch WAS genau TO an Code in das vorher sonst lauffähige Projekt eingefügt hat, denn nach seiner Aussage tritt dieser Fehler ja erst seit seiner letzten Code-Änderung auf. Ich bin mir halt sicher das der Speicher-Fresser wo anders liegt. Da aber nicht mal Code oder ein ordentlicher Stack gepostet wurde sondern nur "OutOfMem" würde ich sagen das wir aufhören uns darüber den Kopf zu zerbrechen was noch alles diesen Fehler in Verbindung mit rekursivem Durchlaufen von Ordnern auslösen kann. So lange uns TO nötige Informationen vorenthält die für uns nun mal zur Lösung wichtig sind KÖNNEN wir nicht helfen. So einfach siehts aus. Und ich glaube kaum das einer von euch mal eben ne Glaskugel und dadurch ne erleuchtung hat ala "in Zeile XXX mal ">" gegen "<" tauschen" ...
Das führt doch zu nichts und für TO scheint das Thema ja schon erledigt zu sein. Warum also weiter Rätzelraten ?