# Zugriffsverweigerung nach Dateitransfer



## TypusMensch (15. Jul 2008)

Hallo, kurz gefasst:


```
public foo(String server, int port, String sourcefilename) throws UnknownHostException, IOException {
        client = new Socket(server, port);
        InputStream is = client.getInputStream();
        OutputStream os = client.getOutputStream();
        //SEND --Pseudo
        sendeAnforderung();
        //RECEIVE --Pseudo
        erhalteDatei();
        //CLOSE
        is.close();
        os.close();
        client.close();
        //OPEN
        if (Desktop.isDesktopSupported()) {
            if (file.exists() && file.canExecute()) {
                Desktop desk = Desktop.getDesktop();
                desk.open(file);
            }
        }
    }
```

Soweit, so gut. sendeAnforderung() und erhalteDaten() habe ich jetzt nur pseudohaft eingefügt. Steht quasi in Wirklichkeit mehr da. Die Datei wird zum Client auch erfolgreich übertragen, liegt damit auf dem Client auf HDD bereit.

Nun aber das Problem: Ich schließe sowohl die Streams, als auch den Socket. Trotzdem erhalte ich dannach, wenn ich die entsprechende Datei öffnen möchte in etwa meist folgenden Aufruffehler: "Zugriff verweigert, Datei wird an einer anderen Stelle aktuell genutzt." Die Datei ist somit in irgendeiner Form noch offen. Bei Textdateien tritt der Fehler z.B. nicht auf, vermutlich weil intern eine Kopie angelegt und geöffnet wird. Office-Dateien hingegen melden den Fehler, PDF ebenso. Ich ging davon aus, dass nachdem ich mit close() alle Stream und den Socket getrennt habe, Zugriff besteht, dem ist nicht so. Schließe ich das Programm, dann kann ohne Probleme die Datei auf der Festplatte öffnen. Woran kann es liegen???

Danke im voraus.
Grüße, Marcus


----------



## Gelöschtes Mitglied 5909 (15. Jul 2008)

wenn ich mich nicht täusch is das ein windoof problem, da windoof die sockets irgendwann mal automatisch schließt, nicht aber unbedingt wenn Socket#close aufgerufen wird.


----------



## TypusMensch (15. Jul 2008)

raiL hat gesagt.:
			
		

> wenn ich mich nicht täusch is das ein windoof problem, da windoof die sockets irgendwann mal automatisch schließt, nicht aber unbedingt wenn Socket#close aufgerufen wird.



Hmmm, "irgendwann" schließe ich mal aus. Wie bereits erwähnt, sobald ich das Programm schließe lässt sich die Datei unverzüglich danach öffnen. Außerdem verliert die Methode dann ja jeglichen Sinn. Vielleicht kann man das ja in irgendeiner Form "erzwingen".

Hint: Mir ist daher auch der Sinn nach file.canExecute() nicht ganz klar, da wie mir scheint, sich die Datei ja nicht wirklich fehlerfrei aufrufen lässt, dennoch hier ein true zurückgegeben wird....


----------



## tuxedo (15. Jul 2008)

Bist du sicher dass du auch den Stream ins Dateisystem geschlossen hast? Der Netzwerkstream hat ja nur indirekt was mit dem Filestream zu tun.

- Alex


----------



## TypusMensch (27. Jul 2008)

Tatsache. Hab hier eine Klasse ByteStream von René Nyffenegger  verwendet. Link: http://www.adp-gmbh.ch/blog/2004/november/15.html

In der Methode toFile(InputStream ins, File file, int len) fehlt ein fos.close();

Danke für die Anregung.


----------



## musiKk (27. Jul 2008)

TypusMensch hat gesagt.:
			
		

> Hint: Mir ist daher auch der Sinn nach file.canExecute() nicht ganz klar, da wie mir scheint, sich die Datei ja nicht wirklich fehlerfrei aufrufen lässt, dennoch hier ein true zurückgegeben wird....



Wieso hint?

canExecute() prueft nur die Rechte. In z. B. UNIX-Dateisystemen hat jede Datei diverse Flags. Wenn das execute-Flag nicht gesetzt ist, kann die Datei nicht ausgefuehrt werden.


----------



## TypusMensch (27. Jul 2008)

Ja, aber ich dachte, dass dieses Flag ggf. gesetzt wird (evl. auch unter Windows), wenn sich die Datei bereits in Ausführung befindet...


----------



## musiKk (27. Jul 2008)

Nein, das Flag sitzt nicht im Betriebssystem, sondern im Dateisystem. Windows kann damit gar nicht umgehen, da kann man ja eh alles ausfuehren. Hauptsache .exe steht hinten.


----------

