Auf File- Befehl warten.

[Ken Park]

Hallo Forum,

ich habe eine Anweisung in einem Programm a la

1: File getEinsend = new File( c:/irgendwoaufderplatte );
2: String[] einsend = getEinsend.list();
3: File datei = new File (c:/irgendwoaufderplatte/einsend[0] );

Die Befehle stehen direkt hintereinander im Code und die Ordnerstruktur sei jetzt hier mal vernachlässigt. Ich möchte also den Inhalt eines Ordners haben und dann über die Dateinamen im Array einsend auf die einzelnen Daten zugreifen. Nun bekomme ich aber allerdings von Zeit zu Zeit eine Nullpointer Exception in Zeile 3, die ich mir nur damit erklären kann, dass Zeile 3 abgearbeitet wird bevor der eigentliche Befehl in Zeile 2 vollständig abgearbeitet worden ist - nebenläufig. Der Verdacht kommt daher, dass diese Befehle manchmal funktionieren und manchmal nicht - mit genau den selben Verzeichnissen usw. Also genau ein Testfall.

Kann ich denn irgendwie auf den Befehl in Zeile 2 warten? Also erst zu zeile 3 gehen wenn der Befehl abgearbeitet ist?
Oder hat jemand noch eine Idee woran es liegen könnte?

gruß.... ken.

 

[SlaterB]

willst du nicht lieber wie ein normaler Programmierer handeln
und z.B. loggen, bei welchen Files der Fehler kommt und bei welchen nicht?

wenn du z.B. auf einen geschützen Order wie den Recycler/ Papierkorb zugreifst, dann liefert getEinsend.list(); null und die NullPointerException ist klar,

ganz ohne irgendeine Nebenläufigkeit

 

[Ken Park]

Hallo,

es handelt sich dabei um Daten mit keinerlei Zugriffsbeschränkung. Und wie ich bereits sagte: Es kann sich (eigentlich) nur um ein Nebenläufigkeitsproblem handeln, da die Testdaten immer die selben sind und es manchmal eben funktioniert und manchmal nicht. Die Daten bleiben die selben.

 

[SlaterB]

tja, aber nur die Nebenläufigkeit läßt sich zumindest auf Java-Seite ausschließen,
der Befehl wird tausendfach auf aller Welt eingesetzt und funktioniert bei allen tadellos,

kaputtes Betriebssystem oder ähnliche Gründe sind natürlich immer die Joker

ich bin noch fürs Loggen, bei welchen Dateien/ Verzeichnissen kommt der Fehler?
schaue direkt danach ins Dateisystem, ob das entsprechende Verzeichnis da ist, sich öffnen läßt oder gar eine normale Datei ist

 

[Ken Park]

Okay, ich werds mal versuchen. Danke schon mal.

 

[ARadauer]

du könntest auch einwenig sauberer programmieren...

if(einsend!=null && einsend.length>0){
			File datei = new File ("c:/irgendwoaufderplatte/einsend[0]");
			usw..
		}

in deinen 3 zeilen gibt es sicher nicht nebläufiges.
wenn in file nix drin ist, liefert list null, daher kommt dein fehler.

dass du beim selben pfad zweimal unterschiedliche ergebnisse erhälst, kann ich mir nicht vorstellen.... könnte höchstens sein, dass windows irgendwelche versteckten datein angelegt hat ..

 

[ARadauer]

generell ist zu sagen, wenn ich eine methode benutze die mir ein array zurück gibt und aber auch null zurück geben kann
muss ich schon prüfen ob es über haupt ein element enhält bevor ich drauf zugreife...

 

[Ken Park]

du könntest auch einwenig sauberer programmieren...

Ja, ich habe nur die essentiellen Zeilen hier ins Forum geschrieben. Exception Handling und Prüfungen habe ich im Orginalcode natürlich verwendet.

dass du beim selben pfad zweimal unterschiedliche ergebnisse erhälst, kann ich mir nicht vorstellen....

Na gut. Was soll ich jetzt dazu sagen? Der Testfall ist wohldefiniert. Die Parameter sind die selben. Die Exception kommt oder eben nicht. Ob man sichs nun vorstellen kann oder nicht.

Aber naja... wenns nicht nebenläufig abläuft muss ich mir eben was neues ausdenken.

 

[ARadauer]

ich habe eine Anweisung in einem Programm a la

zeig bitte mal den genauen code. kann es sein, dass du die mehtoden in unterschiedlichen threads ausführst?

Ob man sichs nun vorstellen kann oder nicht.

ich glaubs dir ja, mich würd jetzt auch interessieren, woran das liegt...

 

[Ken Park]

So... ich verfolg jetzt mal die erste Spur mit den Schreibrechten. Ich hab jetzt mal beispielhaft eine Ordnerstruktur angelegt wo einige Dateien schreibgeschützt sind. Meine Idee ist halt den Ordner vor der Weiterverarbeitung rekursiv zu durchlaufen und ggf. jeden Schreibschutz zu entfernen. Da hab ich aber ein kleines Problem:

Wenn ich mir vor dem Setzen der Rechte per rechte Maustaste im Explorer die Dateizugriffsrechte anzeigen lasse, sehe ich selbstverständlich ein grau unterlegtes Häkchen bei "Schreibschutz". Demnach alles soweit in Ordnung. Ein paar Dateien sind eben schreibgeschützt.

Wenn ich jetzt mit folgendem Code arbeite:

public boolean setRights(File dir){
	String divider = File.separator;
	if (dir.isDirectory()){
			String[] entries = dir.list();
			for (int x=0;x<entries.length;x++){
				File aktFile = new File(dir.getPath()+divider+entries[x]);
				setRights(aktFile);
			}
			if (dir.setWritable(true)) { return true; 	}	
			else { return false; }
		}
		else{
			if (dir.setWritable(true)) { return true; 	}	
			else { return false; }
		}
}

ist nach Beendigung des Programms aber der Schreibschutz nicht entfernt und auch nicht wenn ich zur Laufzeit mit einem Debugger direkt nach diesem rekursiven Befehl anhalte. Habe ich etwas übersehen oder funktioniert das Setzen der Rechte nicht so einfach unter Windows?

 

[Ken Park]

Hmm... ich habe gerade mal mit dem Debugger und ein paar Ausgaben rumgespielt. File.canWrite() und File.canExecute() liefern beide "true", auch wenn im Explorer ein Häckchen bei "Schreibschutz" ist. Scheint also nicht miteinander zu tun zu haben.

Gibts da ne Möglichkeit plattformunabhängig ranzukommen? Oder nur via Runtime und dann per Windows-Befehl?

Ob man sichs nun vorstellen kann oder nicht.

ich glaubs dir ja, mich würd jetzt auch interessieren, woran das liegt...

Also: Ich habe zumindest rausgefunden woher die schreibgeschützten Dateien kommen. Die Dateien auf denen ich es ausführe sind zwar nicht schreibgeschützt, allerdings die Verzeichnisse die ich zur Laufzeit anlege. Zwar nicht schreibgeschützt wie es File.canWrite() liefern würde aber wenn ich die Verzeichnisse über den Explorer -> Eigenschaften öffne sind sie Schreibgeschützt markiert.

Die Frage ist natürlich dann immer noch ob dass der Grund für mein ursprüngliches Problem ist.