Kann Datei oder Ordner nicht löschen

[Dalai]

Kann es sein, dass deine eigene Anwendung in diesem Verzeichnis noch unterwegs ist (durch den Aufruf von ShellExecute)? GetCurrentDir sollte dir das sagen können; ggf. aufrufen vor und nach dem ShellExecute, um zu ermitteln, ob selbiges für das eigene Programm irgendwas am CurrentDir ändert (auch wenn das seltsam wäre).

Grüße
Dalai

[EWeiss]

Zitat von Dalai:

Kann es sein, dass deine eigene Anwendung in diesem Verzeichnis noch unterwegs ist (durch den Aufruf von ShellExecute)? GetCurrentDir sollte dir das sagen können; ggf. aufrufen vor und nach dem ShellExecute, um zu ermitteln, ob selbiges für das eigene Programm irgendwas am CurrentDir ändert (auch wenn das seltsam wäre).

Grüße
Dalai

Was ich sagen kann ist das ich die Directory setze mit dem Programm was das andere aufruft.
Das Aufgerufene ist ja Platt mehr oder weniger wenn es beendet ist.
Eventuell das Problem?

SetCurrentDirectory(PWideChar(sFullPath));

OK! Danke denke das war's habe es entfernt ist nicht unbedingt nötig.
Mitunter sitzt das Problem vor dem Bildschirm

gruss

[Dalai]

Zitat von EWeiss:

Eventuell das Problem?

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 von EWeiss:

Nach dem Auskommentieren von SetCurrentDirectory funktioniert es ja jetzt.

Na Gott sei Dank.
Ich mache hier mal zu.