Datei auf dem kompletten Laufwerk suchen und löschen...

Chris1979

Hallo Autoit Gemeinde

ich weis grad nicht ob ich mich zu doof anstelle oder ob das wirklich so kompliziert ist....
Unsere Anwender haben auf Ihren Rechnern das Tool "Ca2di.exe" liegen. Leider nicht an einer vorgegebenen Stelle sondern wirklich irgendwo auf C
Ganz unerwartet macht die Exe jetzt Probleme und sie muss auf allen Clients runter.

jetzt möchte ich ein Script schreiben was den Laufenden Prozess sofern vorhanden beendet und danach die Datei sucht und löscht.

Der Teil mit dem Prozess ist schnell gemacht
aber beim Rest hab ich nicht man den richtigen Ansatz.

bitte schubst mich mal einer in die richtige Richtung...

AutoIt

#include <MsgBoxConstants.au3>


If ProcessExists("ca2di.exe") Then
    ;MsgBox($MB_SYSTEMMODAL, "", "Prozess wird beendet")
	ProcessClose ( "ca2di.exe" )
Else
EndIf


löschen()


Func löschen()

    Local $Search = FileFindFirstFile("ca2di.exe")

	...ganz viel luft nach oben...

    FileClose($Search)
EndFunc

Alles anzeigen

**AspirinJunkie**

Oh je - bitte auf keinen Fall die gesamte Festplatte nach einer einzelnen Datei durchsuchen - das dauert viel zu lange.

Da der Prozess ja läuft sollte man eher den Pfad des Prozesses auslesen:

AutoIt

#include <WinAPIProc.au3>


Global $s_ProcessName = "ca2di.exe"
Global $s_ProcessPath = _WinAPI_GetProcessFileName (ProcessExists($s_ProcessName))


ConsoleWrite($s_ProcessPath & @CRLF)

Chris1979

Ja das geht leider nicht weil der Prozess nicht bei allen Rechnern läuft und da der Job über Nacht kommt kann der pro Pc ruhig 2 stunden rumjuckeln
Problem ist das sich die Anwender die Exe dahin gespeichert haben wo sie grade lustig waren, ist eine der wenigen Anwendungen die nicht über die CA Softwareverteilung kommt leider.

**BugFix**

Nun, wenn die exe läuft ist es ja kein Problem. Falls nicht solltest du erst mal sondieren, wo diese gepeichert sein kann, anhand der User-Rechte. Deine User werden wohl kaum die Rechte haben im Programm- oder Systemordner zu schreiben.
Somit würde ich erst mal eine Auflistung nur vom Rootpfad erstellen. Von den gefundenen Ordnern die eben benannten ausschliessen. Auch den Benutzerordner würde ich erst mal aussen vorlassen. Was übrig ist, kannst du nun rekursiv durchsuchen. Sollte das nix bringen musst du wohl oder übel den Benutzerordner durchsuchen. Lass dort aber bitte \AppData aussen vor - da liegen einige GB Daten und da dieser Ordner normalerweise nicht sichtbar ist, ist es auch unwahrscheinlich, dass die exe dort gelandet ist.
Viel Erfolg.

**AspirinJunkie**

Der Prozess öffnet sich doch nicht von Geisterhand.
Der muss ja irgendwo eingetragen sein.
Im Autostart-Ordner / in den Autostarteinträgen der Registry / im Task Sheduler?

Wenn der Prozess z.B. über den Task-Sheduler aufgerufen wird, würde ich die Tasks danach durchsuchen:

AutoIt

Global $s_ProcessName = "ca2di.exe"


Local $oWMI = ObjGet("winmgmts:{impersonationLevel=impersonate}!\\\localhost\root\CIMV2")
If IsObj($oWMI) Then
	For $oItem In $oWMI.ExecQuery("SELECT * FROM Win32_ScheduledJob", "WQL", 48)
		If StringInStr($oItem.Command, "ca2di.exe") Then
			MsgBox(0, "Gefunden!", $oItem.Command & @CRLF & $oItem.Caption)
			; Task löschen: $oItem.Delete()
		EndIf
	Next
EndIf

Alles anzeigen

Hätte auch den Vorteil, dass du den Task gleich löschst und keine Taskleiche übrig bleibt wenn du nur die exe löschst.

Chris1979

Ich bin ja prinzipiell bei euch aber leider können unsere Anwender die Datei wirklich an fast jeden beliebigen Punkt auf dem PC geschoben haben.

Ich hab remote auf 5 Systemen geschaut
System 1 exe liegt auf dem Desktop Autostart NEIN
System 2 exe liegt in C:\Temp Autostart NEIN
System 3 exe liegt in C:\Users\Uxxxx\AppData\Roaming Autostart JA
System 4 exe liegt in C:\Users\Uxxxx\Downloads Autostart JA
System 5 exe liegt in C: \Siemens\ca2di.exe Autostart JA

Unsere Hotline Jungs sind heute nur noch am ... weil ständig jemand anruft

wär also klasse wenn jemand mir nen Tip gibt wie ich wirklich das komplette C Laufwerk durchsuchen kann um dieses Drecktool zu löschen.

**BugFix**

Na dann durchsuche C:\ rekursiv. Aber nicht, indem du direkt C:\ angibst (da wird sich dein Rechner wahrscheinlich wegen der Rekursionstiefe aufhängen), sondern liste C:\ in ein Array und starte von den Ergebnissen die rekursive Suche.

Oder liegt dein Problem an der rekursiven Suche? Da findest du diverse Lösungen hier im Forum.

**AspirinJunkie**

Zitat von Chris1979

aber leider können unsere Anwender die Datei wirklich an fast jeden beliebigen Punkt auf dem PC geschoben haben

Deswegen sag ich ja die ganze Zeit das ein Durchsuchen des gesamten Laufwerkes Blödsinn ist.
Wie wird der Prozess gestartet? - dort findest du auch den korrekten Pfad ohne das Laufwerk zu durchsuchen.

Hier mal noch ne Alternative falls der Prozess über den Task Sheduler gestartet wird:

AutoIt

Global $s_ProcessName = "ca2di.exe"


$o_TS = ObjCreate("Schedule.Service")
$o_TS.Connect()


$o_RootFolder = $o_TS.GetFolder("\")
$col_Tasks = $o_RootFolder.GetTasks(0)


For $o_Task In $col_Tasks
	For $o_Action In $o_Task.Definition().Actions
		If $o_Action.Type = 0 Then
			If StringInStr($o_Action.Path, $s_ProcessName) Then
				MsgBox(0, "Gefunden!", $o_Task.Name & @CRLF & @CRLF & $o_Action.Path)
				; Task Löschen: $o_RootFolder.DeleteTask($o_Task.Name)   - benötigt u.U. ein #requireadmin
			EndIf
		EndIf
	Next
Next

Alles anzeigen

gmmg

sperre die exe doch per Gruppenrichtlinie ...

google suche -> mit AppLocker Programme per Richtlinien sperren

gruß gmmg

Chris1979

Wald bäume und so Applocker hatte ich gar nicht auf dem Schirm...
ist erledigt

Danke^^

**Oscar**

Wobei ich jetzt auch die rekursive Suche auf der ganzen Platte nicht so tragisch finden würde.
Habe das gerade mal mit meiner "F"-Platte (keine SSD) gemacht (2 TB, davon 1.5 TB belegt mit ca. 600.000 Dateien in mehr als 10.000 Ordnern).
Das Script hat 154 sek. gebraucht um alle Dateien zu durchsuchen:

AutoIt

#include <Array.au3>
#include <File.au3>
$iTimer = TimerInit()
$aFileList = _FileListToArrayRec('f:\', 'ca2di.exe', $FLTAR_FILES, $FLTAR_RECUR, $FLTAR_NOSORT, $FLTAR_FULLPATH)
ConsoleWrite(TimerDiff($iTimer) & @CR)
_ArrayDisplay($aFileList)

und das beim ersten Suchlauf, also ohne dass sich das Directory im Cache befindet. Beim zweiten Start dauert das ganze nur 6-7 sek.

**AspirinJunkie**

Folgende Funktion ist wahrscheinlich sogar noch schneller:

AutoIt

$iTimer = TimerInit()
$aFileList = FLwStr('F:\', '^ca2di\.exe$')
ConsoleWrite(TimerDiff($iTimer) & @CR)
_ArrayDisplay($aFileList)






; #FUNCTION# ======================================================================================
; Name ..........: FLwStr()
; Description ...: Findet Dateien und/oder Ordner in einem Verzeichnisbaum
; Syntax ........: FLwStr($sSD, Const[ $sPat = '', Const[ $iF = 3]])
; Parameters ....: $sSD           - Suchort (mehrere Suchorte durch | trennen)
;                 Const $sPat    - [optional] regulärer Ausdruck für zu findende Datei/Ordnernamen (default:'')
;                  Const $iF      - [optional] 1=nur Dateien, 2=nur Ordner, 3=Dateien+Ordner (default:3)
;                  Const $iSSFlag - [optional] 0=Rückgabearray mit Anzahl Elemente in $Array0, 2=Rückgabearray ohne Anzahl Elemente
; Return values .: Success - Return Array with Matches with $Array[0] = Count
;                  Failure - Return "" and set @error
; Author ........: AspirinJunkie
; Remarks .......: Funktionsweise ist iterativ - nicht rekursiv
; Example .......: Yes
;                  #include <Array.au3>
;                  $aTmp = FLwStr(@WindowsDir & '|' & @ProgramFilesDir, "^Temp$", 2)
;                  _ArrayDisplay($aTmp)
; =================================================================================================
Func FLwStr($sSD, Const $sPat = '', Const $iF = 3, Const $iSSFlag = 0)
	;by AspirinJunkie
	Local $sRet = "", $sSubD = ""
	For $i In StringSplit($sSD, '|', 2)
		If StringRight($i, 1) = '\' Then $i = StringTrimRight($i, 1)
		If Not FileExists($i) Then Return SetError(2, 0, "")
		$sSubD &= '|' & $i
	Next
	Local $FFFF, $FFNF, $sDir, $iC
	Local $aD, $hDLL = DllOpen('kernel32.dll')
	If Not ($iF = 3 Or $iF = 1 Or $iF = 2) Then Return SetError(3, 0, "")
	Do
		$iC = StringInStr($sSubD, '|', 2, -1)
		If @error Or $iC = 0 Then ExitLoop
		$iC = StringLen($sSubD) - $iC
		$sDir = StringRight($sSubD, $iC)
		$sSubD = StringTrimRight($sSubD, $iC + 1)
		$FFFF = FileFindFirstFile($sDir & '\*')
		If $FFFF <> -1 Then
			Do
				$FFNF = FileFindNextFile($FFFF)
				If @error Then ExitLoop
				If @extended Then
					If BitAND(StringRegExp($FFNF, $sPat) * 2, $iF) Then $sRet &= $sDir & '\' & $FFNF & '\|'
					$aD = DllCall($hDLL, 'dword', 'GetFileAttributesW', 'wstr', $sDir & '\' & $FFNF)
					If @error Or BitAND($aD[0], 0x400) Then ContinueLoop
					$sSubD &= '|' & $sDir & '\' & $FFNF
				ElseIf BitAND(StringRegExp($FFNF, $sPat), $iF) Then
					$sRet &= $sDir & '\' & $FFNF & '|'
				EndIf
			Until 0
			FileClose($FFFF)
		EndIf
	Until 0
	DllClose($hDLL)
	Return StringSplit(StringTrimRight($sRet, 1), '|', $iSSFlag)
EndFunc   ;==>FLwStr

Alles anzeigen

Und man kann es noch erheblich weiter optimieren wenn man z.B. nach dem ersten Fund die Suche abbricht.

Darum geht es im Grunde hier aber nicht.
Wenn eine Datei per Aufgabenplanung zu bestimmten Zeiten aufgerufen wird, ist es einfach unsauber die Datei nur zu löschen oder gar nur zu blockieren.
Das ist Symptombekämpfung - die Ursache (der Task bzw. die Datei bei der Blockierung) bleibt als Leiche bestehen.

Den Task ausfindig machen der das ganze verursacht und damit sowohl Task als auch Datei killen ist die schnellste und sauberste Variante dieser Lösungen.

**Oscar**

AspirinJunkie:
Für den Test habe ich sogar noch meinen Rechner neu gestartet.
Dein Script ist in der Tat noch schneller: ca. 126 sek. beim ersten Durchlauf und ca. 5 sek. beim zweiten Durchlauf.

Und die Platte ist nicht die neueste/schnellste: 5400 rpm / SATA300 / 32 MB Puffer

**Kanashius**

Hab mir die Suche gleich mal gespeichert
243572.6667 für 1 Datei bei 1283160 Dateien in 104388 ordnern (1,1 TB)
14816.3081 beim 2ten mal. (Wo speichert der die Infos eigentlich alle? Im Arbeitsspeicher ja wohl nicht...). Ich hab die Ordner ja nicht indiziert für die Suche.

Peter S. Taler · *Ab 19-10-22 ergänzt um:*

dazu brauchts aber nun wirklich kein autoit scribt.
Meine Herren darf ich erinnern:

DEL [/P] [/F] [/S] [/Q] [/A[[:]Attribute]] Namen
ERASE [/P] [/F] [/S] [/Q] [/A[[:]Attribute]] Namen

Namen Gibt eine Liste von Dateien oder Verzeichnissen an.
Platzhalter können verwendet werden, um mehrere Dateien zu
löschen. Wird ein Verzeichnis angegeben, werden alle Dateien
diesem Verzeichnis gelöscht.
/P Fordert Sie vor dem Löschen jeder Datei zur Bestätigung auf.
/F Erzwingt das Löschen schreibgeschützter Dateien.
/S Löscht alle Dateien in allen Unterverzeichnissen.
/Q Keine Rückfrage bei Benutzung globaler Platzhalter.
/A Wählt die zu löschenden Dateien nach dem Attribut aus.
Attribute R Schreibgeschützte Dateien S Systemdateien
H Versteckte Dateien A Zu archivierende Dateien

das ist ein 1/4 zeiler.......

ab und an darf es noch DOS sein?

Um verweise aus der reg zu löschn... mit einem Nir soft tool selbige durchsuchen..

**AspirinJunkie**

Zitat von Peter S. Taler

ab und an darf es noch DOS sein?

WIeso DOS?
Das ist ein Befehl des Kommandozeileninterpreters cmd.exe.
DOS innerhalb von Windows gibt es schon seit Windows ME nicht mehr.
Unter DOS gab es zwar auch ein DEL - das hatte aber nicht die volle Funktionalität des cmd-DEL (konnte nur DEL [drive:][path]filename [/P])

Zitat von Peter S. Taler

Um verweise aus der reg zu löschn... mit einem Nir soft tool selbige durchsuchen..

Leider ignoriert der Threadstarter eine Ursachenbekämpfung.
Er hält lieber daran fest die Datei umständlich zu suchen oder ihren Aufruf zu blockieren.

Peter S. Taler · *Ab 19-10-22 ergänzt um:*

musst du es auf die goldwaage legen ?
auf diesem niveau können wir dann auch noch zwischen cmd und command unterscheiden. oder die leistungsfähigkeit des befehls vom bs abhängig machen. möchtest du da bei win 3.11 anfangen und dich bis win xyz hocharbeiten? oder eben umgangssprachlich dos, unabhängig davon ob pure dos oder eben emuliert? solche haarspaltereien sind in diesem zusammenhang nicht ZIELFÜHREND.

umständlich finde ich löschen mit einem befehl wie del nun wirklich nicht. wie einfach das geht kannst du ja mal ausprobieren es gäbe da den wirklich einfachen befehl - nein das verkneife ich mir - sonst macht das wirklich jemand....

gruß

peter

**AspirinJunkie**

Zitat von Peter S. Taler

umständlich finde ich löschen mit einem befehl wie del nun wirklich nicht.

Nicht der Befehl ist umständlich - das was der Computer aufgrund dieses Befehles alles durchführen muss ist umständlich.
Außerdem: Wenn die Datei einfach nur gesucht und gelöscht wird bleiben deren Autostarteinträge immer noch bestehen - das Suchen und Löschen ist ergo keine saubere Lösung.

Zitat von Peter S. Taler

musst du es auf die goldwaage legen ?

Ja weil die Befehle eben nicht die selbe Funktionalität besitzen.
Wenn man von Anfang zwischen DOS und cmd trennt wird kein Nutzer dazu verleitet in google "DOS del" einzutragen und dann dort auf irreführende Ergebnisse zu stoßen.

Peter S. Taler · *Ab 19-10-22 ergänzt um:*

vielleicht schaust du dir mal den beitrag an....

http://www.computerhope.com/delhlp.htm oder den
https://en.wikipedia.org/wiki/Del_(command) oder lieber den
https://de.wikibooks.org/wiki/Batch-Pro…e_DOS-Kommandos

es gibt noch ein paar tausend artikel, die es dos nennen. es wird DOS genannt. egal ob wir übr reines DOS oder cmd oder command.com sprechen. DOS - so finden es auch die suchmaschinen. unterscheidest du auch batch scripte für dos und cmd? oder wie nennst du win xp in einer vm? ist das kein xp? von version zu version kann sich der befehlsumfang und die syntax ändern. da ist es unerheblich ob cmd oder DOS. da ist es schon wichtiger ob cmd unter xp /vista/win7 oder ev. cmd unter xp wiederhesrstellungskonsole? also der begriff cmd regelt auch keine syntax oder keinen befehlsumfang.

Das es unterschiede im befehlsumfang gibt ist nix neues - das ist auch in autoit so. von version zu version ändert sich schon mal was am befehlssatz. Muss man es daher auf die spitze der wortklauberei treiben?

ob es für meinen computer umständlich ist etwas zu suchen oder nicht - ist mir meist wurscht. solange sich die zeit die er sich nimmt in erträglichen grenzen hält - und da kommt es - scriptgesteuert - mal auf einige 10 sekunden hin oder her nicht an. es mag für komplexe programme für interesse sein ob ein befehl umständlich ist oder nicht - die masse solcher umständlichen macht ein programm langsam - für ein script - das ein problem lösen soll ist es meist unerheblich (ja schon klar - auch da gibt es dinge die besser fix gehen) aber in diesem fall?

es gilt: wenn mein computer mal arbeien muss - dann stört mich das wenig. ab und an machts ja nix wenn die kisten statt tiefschlaf auch mal wach sind:)

wenn chris 1979 einen verweis in den autostart datein hätte - müßte er die dateien nicht suchen!

Peter

**BugFix**

Leute - Bitte!
Seit Post #10 ist das Thema für den TE erledigt. Wenn also noch weiterführende Grundsatzdiskussionen geplant sind, bitte nach OT oder in den PN-Bereich verschieben.
Danke.