Kann Datei oder Ordner nicht löschen

[Redeemer]

Zitat:

Zitat von EWeiss (Beitrag 1419814)

Zitat:

Zitat von KodeZwerg (Beitrag 1419811)

Wenn Du was nicht löschen kannst, hat noch irgendwas Zugriff.
Ich kann nicht Hellsehen, dafür gibts den Unlocker.
Der zeigt Dir welcher Process/welches Handle da noch mit rumhantiert.

Bitte!
Ich bitte nicht oft aber beantworte keine fragen mehr auf meine Fragen.
Leider kann ich dich nicht blocken.

gruss

Kannst du bitte aufhören, wieder derart aggressiv gegen die Community zu agieren? Mir fällt da diese Aktion ein.

[EWeiss]

Zitat:

Zitat von Redeemer (Beitrag 1419824)

Zitat:

Zitat von EWeiss (Beitrag 1419814)

Zitat:

Zitat von KodeZwerg (Beitrag 1419811)

Wenn Du was nicht löschen kannst, hat noch irgendwas Zugriff.
Ich kann nicht Hellsehen, dafür gibts den Unlocker.
Der zeigt Dir welcher Process/welches Handle da noch mit rumhantiert.

Bitte!
Ich bitte nicht oft aber beantworte keine fragen mehr auf meine Fragen.
Leider kann ich dich nicht blocken.

gruss

Kannst du bitte aufhören, wieder derart aggressiv gegen die Community zu agieren? Mir fällt da diese Aktion ein.

Es wurde alles gesagt!

gruss

[Dalai]

Zitat:

Zitat von EWeiss (Beitrag 1419821)

Eventuell das Problem?

Delphi-Quellcode:

SetCurrentDirectory(PWideChar(sFullPath));

Jep, das ist ein Problem. Sinnvoller/besser ist es, wenn du ShellExecute das Arbeitsverzeichnis in lpDirectory übergibst. Oder gibt es einen Grund, warum dein Programm ebenfalls dieses Verzeichnis als aktuelles Verzeichnis setzen müsste?

Grüße
Dalai

[hoika]

Hallo,

Zitat:

Was kann den Zugriff auf die Datei blockieren? Obwohl diese geschlossen wurde.
Wüsste jetzt nichts darüber das ShellExecute den Zugriff auf Dateien verwehrt nachdem diese geschlossen wurde.

Hm, dann war dir schon klar, dass deine eigene Anwendung Schuld ist,
deren Quellcode wir nicht kennen.
Eine Auskommentieren des ShellExecute hätte Dir gezeigt, dass es nicht dieser Befehl ist.

Wenn Du hier Hilfe erwartest, erwarten wir den freundlichen Fragesteller
und nicht den aggressiven "Ich würde dich gern blocken" Antworter.

PS:
Wir haben gerade das gleiche Problem mit einem USB-Stick,
der sich nach dem Schreiben einer Datei (ohne vorheriges SetCurrentDirectory) nicht freigeben läßt.
Ich hänge der Kollegin diesen Thread-Link mal an ;)

[EWeiss]

Zitat:

Oder gibt es einen Grund, warum dein Programm ebenfalls dieses Verzeichnis als aktuelles Verzeichnis setzen müsste?

Wie du schon schreibst es ist das Arbeitsverzeichnis des Programms das ich über einen *.lnk oder direkt starte.
Den weise ich dann zu.
Einen anderen Grund dafür gibt es nicht.

Zitat:

Hm, dann war dir schon klar, dass deine eigene Anwendung Schuld ist, deren Quellcode wir nicht kennen.

Den hatte ich hier schon des Öfteren hochgeladen "OTTB"

Und ja wenn ich eine andere Anwendung starte und anschießend der Pfad dieser geblockt wird kann es nur die eigene Anwendung sein die das Problem verursacht.
Da brauche ich kein Spy-Werkzeug was mir sagt welches Handle\Prozess zugriff auf den Ordner hat.

Zitat:

Eine Auskommentieren des ShellExecute hätte Dir gezeigt, dass es nicht dieser Befehl ist.

Nein hätte es nicht, denn wenn ich die fremde Anwendung nicht vorher starte wird der Ordner auch nicht geblockt.

Zitat:

Sinnvoller/besser ist es, wenn du ShellExecute das Arbeitsverzeichnis in lpDirectory übergibst.

Delphi-Quellcode:

// SetCurrentDirectory(PWideChar(sFullPath));
...
ShellExecuteW(0, nil, PWideChar(sShellTo), PWideChar(sCmdLine), PWideChar(sFullPath),
  Sprite.ShowCmd);

Das tue ich ja..

Nach dem Auskommentieren von SetCurrentDirectory funktioniert es ja jetzt.
Danke! @Dali

gruss

[Daniel]

Zitat:

Zitat von EWeiss (Beitrag 1419850)

Nach dem Auskommentieren von SetCurrentDirectory funktioniert es ja jetzt.

Na Gott sei Dank.
Ich mache hier mal zu.