Kann Datei oder Ordner nicht löschen

[EWeiss]

Habe ein kleines Problem festgestellt.

Wenn ich mit ShellExecute ein Programm starte Normaler Parameter SW_SHOW kann ich wenn die gestartete Anwendung geschlossen wurde
den Folder dieser gestarteten Anwendung nicht löschen\umbenennen etc.. erst wenn ich die Anwendung beende mit der diese vorher mit ShellExecute Aufgerufen wurde.

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.

gruss

[KodeZwerg]

Du kannst mit Download Windows Unlocker herausfinden welches Handle da noch offen ist.

[EWeiss]

Zitat:

Zitat von KodeZwerg (Beitrag 1419807)

Du kannst mit Download Windows Unlocker herausfinden welches Handle da noch offen ist.

Welches Handle wenn die Anwendung geschlossen ist.
Da gibt es keins mehr.

Und die Anwendung welche die andere gestartet hat will ich nicht extra dafür schließen.

gruss

[KodeZwerg]

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.

[EWeiss]

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

[KodeZwerg]

Alles klaro, adios amigo, war 'ne schöne Zeit.

[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:

Zitat von Dalai (Beitrag 1419820)

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?

Delphi-Quellcode:

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

[zeras]

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

Mit der Info von Codezwerg wärest du aber schon auf dem richtigen Weg gewesen. Ohne es zu probieren, hätte wohl der Unlocker dein aufrufendes Programm angezeigt.:lol:

[EWeiss]

Zitat:

Zitat von zeras (Beitrag 1419822)

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

Mit der Info von Codezwerg wärest du aber schon auf dem richtigen Weg gewesen. Ohne es zu probieren, hätte wohl der Unlocker dein aufrufendes Programm angezeigt.:lol:

Bla, bla.
Das es von meinem Ausführenden Programm ausging war mir klar dafür brauche ich keine Fremdanwendung die mir sagt welches Programm hier den Ordner blockt.
Das war auch nicht die frage sondern ob es durch ShellExecute ausgelöst wird bzw. durch was es geblockt (Funktion) wird.
Und ich lade bestimmt kein Fremd Programm um meine Programmtechnischen Ungereimtheiten zu lösen.

Letztendlich hätte es mir nur gesagt was ich schon wusste! Mehr ist da nicht zu sagen.

gruss

[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.