Ist tDirectory Threadsicher?

[fisipjm]

Hi,

mal eine etwas allgemeinere Frage:

Ist TDirectory.Delete threadsicher? Mal ganz davon abgesehen, wie es grundsätzlich damit aussieht einen Ordner zu löschen und dort nicht sich gegenseitig die Struktur weg zu ziehen, dieses Problems bin ich mir bewusst. Ich versuche das auch zu umgehen, indem ich erst prüfe ob der Ordner vorhanden ist, ihn dann umbenenne und dann erst lösche. Schließt das Risiko nicht zu 100% aus, aber minimiert es für mich auf ein akzeptables Mindestmaß.

Folgende Konstellation die ich nicht wirklich zum laufen bekomme. Mein Projekt wird als ISAPI DLL auf einem IIS laufen. Der erstellt mir für jede Request von einem neuen Benutzer/IP das Webmodule neu. Die DLL schreibt die Zugriffe in Logdateien in separierte Ordner. Ich möchte jetzt beim Erstellen des Webmoduls prüfen, ob ein Ordner mit der Bezeichnung Heutiges Datum minus X Tage existiert und wenn ja, dann möchte ich es löschen. Funktioniert auch Problemlos, solange ich das im Main-Thread laufen lasse. Das Problem das ich aber nun habe ist, dass dann der erste Abruf auf den Endpunkt nach dem Datumswechsel, genau so lange länger braucht wie der Ordner braucht um gelöscht zu werden. Das kann je nach Größe länger dauern. Das wollte ich vermeiden indem ich den Löschprozess in einen Thread werfe. Mit TTask.Run normalerweise keine große Sache, dachte ich. Aber dann funktioniert weder das Umbenenne noch das Löschen. Hab schon gedacht es liegt vielleicht daran, dass das Webmodul wieder freigegeben wird, also hab ich den Task in eine ITask Objekt gepackt und im Destroy des Webmoduls erst noch auf ein WaitAny geprüft. Hat leider auch nicht geholfen.

Habt ihr noch Ideen was es sein könnte?

[Der schöne Günther]

Zitat von fisipjm:

Aber dann funktioniert weder das Umbenenne noch das Löschen.

Jetzt wäre doch der interessante Teil, sich mit einem Debugger dahinter zu klemmen oder generell zu schauen, was genau nicht funktioniert. Log doch irgendwo weg, was er grade löscht, wie viele Dateien er gefunden hat/gedenkt zu löschen und wo es hängt. Auch von SysInternals gibt es viele Tools die dir als Mini-Debugger anzeigen könnten, was der grade liest und löscht- https://learn.microsoft.com/en-us/sy...nloads/procmon

[Kas Ob.]

Hi,

Zitat von fisipjm:

Habt ihr noch Ideen was es sein könnte?

I would suggest the most important thing, check the operation result, i mean file/folder deletion if it is executed then log the last error, this will reveal most the details to find a fix, did the delete reached? did it fail? why it fail ?

About why it fail, i suspect it is a permission problem as it is complex and complicated permission between the isolated IIS worker process, and threads created by it, the user of the worker which is part of IIS_IUSRS, but which one ?
Also notice your running user is configured by IIS application pool identity.

Now from https://learn.microsoft.com/en-us/tr...ns-user-rights
You can see that there is very different permissions for specefic paths and users, take an example of "\inetpub\wwwroot", IIS_IUSRS can only "Read & execute" meaning no writing (and even no listing), no writing means no deletion, this easily can be reported by GetLastError.

Also i would recommend against running your own threads, by creating them with TThread.Create or CreateThread Directly, or by calling from the RTL like ITask, these threads are your own and will run outside of the IIS scope of control, keeping in mid IIS can and might terminate (yes terminate) threads at any moment, any synchronization/waiting between these groups can only leads to all sort of problem, if you really want background threads then create one or few from the DLL itself, and comunicate them with messages or any other fitting way, keepingin mind they (IIS threads) might be killed, so no waiting.

[peterbelow]

Zitat von fisipjm:

Hi,

mal eine etwas allgemeinere Frage:

Ist TDirectory.Delete threadsicher? Mal ganz davon abgesehen, wie es grundsätzlich damit aussieht einen Ordner zu löschen und dort nicht sich gegenseitig die Struktur weg zu ziehen, dieses Problems bin ich mir bewusst. Ich versuche das auch zu umgehen, indem ich erst prüfe ob der Ordner vorhanden ist, ihn dann umbenenne und dann erst lösche. Schließt das Risiko nicht zu 100% aus, aber minimiert es für mich auf ein akzeptables Mindestmaß.

Folgende Konstellation die ich nicht wirklich zum laufen bekomme. Mein Projekt wird als ISAPI DLL auf einem IIS laufen. Der erstellt mir für jede Request von einem neuen Benutzer/IP das Webmodule neu. Die DLL schreibt die Zugriffe in Logdateien in separierte Ordner. Ich möchte jetzt beim Erstellen des Webmoduls prüfen, ob ein Ordner mit der Bezeichnung Heutiges Datum minus X Tage existiert und wenn ja, dann möchte ich es löschen. Funktioniert auch Problemlos, solange ich das im Main-Thread laufen lasse. Das Problem das ich aber nun habe ist, dass dann der erste Abruf auf den Endpunkt nach dem Datumswechsel, genau so lange länger braucht wie der Ordner braucht um gelöscht zu werden. Das kann je nach Größe länger dauern. Das wollte ich vermeiden indem ich den Löschprozess in einen Thread werfe. Mit TTask.Run normalerweise keine große Sache, dachte ich. Aber dann funktioniert weder das Umbenenne noch das Löschen. Hab schon gedacht es liegt vielleicht daran, dass das Webmodul wieder freigegeben wird, also hab ich den Task in eine ITask Objekt gepackt und im Destroy des Webmoduls erst noch auf ein WaitAny geprüft. Hat leider auch nicht geholfen.

Habt ihr noch Ideen was es sein könnte?

Ich würde die Aufgabe, alte Logordner abzuräumen nicht der ISAPI DLL überlassen sondern dafür ein eigenes Programm (ohne UI) erstellen, das dann regelmäßig als Hintergrund-Task vom OS ausgeführt wird. Das vermeidet alle Konflikte mit dem Webservice, da der ja auf solch alte Verzeichnisse nicht mehr zugreifen sollte. Für sowas gibt es in Windows den Task Scheduler, andere Betriebssysteme haben sicher 'was äquivalentes.