VisualBasic Prozess ermitteln, der Ordner löscht

[easy.2ci]

Hallo,

folgende Situation. In einer riesigen Serverfarm werden 100 neue Programme am Stück installiert. Danach fehlt 1 Ordner, auf den aber 1 Anwendung angewiesen ist.

Sagen wir mal der Ordner heisst C:\test

Ich brauche nun was, womit ich sehen kann, welcher Prozess den Lösch Befehl auf diesen Ordner abgesetzt hat. Da kam mir als erstes der Filemon/procmon von Sysinternals in den Sinn. Problem dabei: Die 100Programminstallationen dauern etwa 24 Stunden. Pro Minute wird aber von Filemon 1GB Log geschrieben, da die Server echt unter Dampf stehen.

Das sind also etwa 1400GB Logs pro Server. Wir reden hier über etwa 2000Server, die man nur gleichzeitig bedienen kann. Ich kann mir also nicht einen einzelnen schnappen und getrennt betrachten. Klar gibts ne Testumgebung, aber da tritt das Problem nicht auf.

Wir sprechen hier also von 2,8 Millionen GB, oder 2000 TeraBytes oder eben 2 PetaBytes.
Das ist selbst für das dickste Enterprise SAN zuviel.

Klar kann ich im Filemon filtern, aber Filmon filtert nur die Anzeige und captured im Hintergrund fleissig eben doch ungefiltert alles.


Die Objektüberwachung von Windows bringt auch nichts, da dann im Sicherheitslog lediglich der User steht, der den Löschbefehl auf C:\test abgesetzt hat. Das nützt mir aber nichts, da die 100 Programminstallationen alle unterm gleichen User laufen. Ich brauche daher den Prozess, der den Löschbefehl absetzt.

VB, C#, C... alles kein Problem.

Hat da einer eine Idee zu? Der Filemon kann es ja auch. Hab nur keine Ahnung, wie der Filemon an die Liste der aktuellen Aktivitäten kommt.

 

[gigajum]

In Filemon einen Filter einsetzen welcher genau den Namen des betreffenden Ordners hat evtl. den kompletten Pfad, dann werden nur Aktionen aufgelistet die genau diesen Ordner Betreffen

Ok war zu blöd zum lesen, genau beim scrollen den Absatz übersprungen 4 get it

 

[Fr4g3r]

Hi,

wird der Ordner denn gleuch zu beginn erstellt?
Wenn ja, dann könntest du für die Zeit der Installation ja entweder nen Schreibschutz auf den Ordner setzen oder dem Benutzer unter dem die Installation läuft nur leserechte auf den Ordner geben.
Damit kannste das Problem vielleicht umgehen.


Gruß

 

[DrToxic]

Vielleicht den Ordner auf nur-lesen setzen bzw für die Dauer der Installation die Benutzerrechte für den Ordner beschränken?


edit: zu langsam

 

[easy.2ci]

Das mit dem Rechte einschränken ist eine interessante Idee. Muss ich morgen mal mit Kollegen diskutieren. Dann könnten wir auf lästige Reparatur Scripte verzichten.

Der Ordner C:\test ist schon vor den Programminstallationen da, daher hat man hier wohl die Möglichkeit anzusetzen.

Eine dauerhafte Lösung ist aber nur, daß Programm zu finden, welches das Löschen verursacht. Ich habe dazu mal Testprogramme geschrieben, die den Ordner überwachen. Jedoch komme ich nicht soweit, daß ich den Prozess gemeldet bekomme, sondern lediglich daß der Ordner gelöscht wurde.

 

[Merle]

Oder in eurem Installscript den Ordner direkt nach der Programminstallation in c:\temp1 umbenennen, und dann, wenn er wieder gebraucht wird, den inhalt von temp1 in temp kopieren. (Falls Temp zu diesem Zeitpunkt wieder existiert, um die Ordner zu mergen, kopieren und nicht wieder umbenennen).

 

[DrToxic]

darf man fragen, ob's geklappt hat?

 

[easy.2ci]

Das Problem ist mittlerweile gelöst. Zwar nicht mit meiner ursprünglichen Idee ein Programm zu entwickeln, welches den Prozess ermittelt, sondern der Entwickler des Programms das den Stress verursacht hat den Fehler selbst entdeckt und uns aus der Administration gemeldet.

War auch kein Programmierfehler, sondern wir haben da einen Compilerfehler gefunden, der ein Fehlverhalten bei seltenen Exceptions aufweist und dann unkontrolliert löscht. Fehler st dem Compiler Hersteller gemeldet der wiederrum eine Korrektur bringen wird.


Ursache gefunden, Problem gelöst, 2000 Terminal Server sind grad in der Neuinstallation ;-)


Die gelöschten Ordner wiederherstellen ging nicht, da die Ordner während der nachfolgende Programmläufe mit NTFS Rechten versehen wurden. Diese zu ermitteln und per Script nachzupflegen hätte noch länger gedauert, als die Neuinstallationen.