Warum dem so kann ich dir nicht sagen, aber du könntst ja ein if FileExists nutzen um das löschen zu unterbinden?!
Du musst die Datei auch dementsprechend sperren: https://www.autoitscript.com/forum/topic/13…t-process-only/
Den Link hatte ich auch schon gefunden.
Frage :
Die <WinAPIEx.au3> (genauer <WinAPIFiles.au3>) enthält u.A. folgende Funktionen :
_WinAPI_FileInUse , _WinAPI_LockFile , _WinAPI_UnlockFile
_WinAPI_FileInUse meldet z.B. korrekt, wenn eine Datei mit FileOpen geöffnet ist (dazu gibt es auch eine Hilfe).
Zu _WinAPI_LockFile und _WinAPI_UnlockFile habe ich allerdings keine Hilfe gefunden. Vom Namen her sind das aber Kandidaten, die eine Dateisperre setzen/aufheben sollten. Weißt Du mehr darüber ?
Gruß Musashi
Sorry aber was soll das bringen? Das File existirt. Ja auch bei Fileopen. Nur - du kannst es löschen trotz Du es geöffnet hast. Es geht nicht darum festzustellen ob ein File vorhanden ist.
Sondern darum, dass ein File, das vorhanden ist, geöffnet ist (zum Schreiben) gelöscht werden kann via explorer. Leg ein file Text.txt an. öffne es in Autoit ruf einen MSGbox auf - nimm den Explorer und lösch das text.txt - Das dürfte nach meiner Auffassung nicht funktionieren - tut es aber !
War noch nicht richtig wach 
Zu _WinAPI_LockFile und _WinAPI_UnlockFile habe ich allerdings keine Hilfe gefunden.
https://www.autoitscript.com/autoit3/docs/l…PI_LockFile.htm
https://www.autoitscript.com/autoit3/docs/l…_UnlockFile.htm
Da sind sie doch? Ich schätze mal die UDF war vor der Wrapperfunktion da, ansonsten hätte man direkt die _WinAPI-Funktion aus der internen UDF nehmen können.
Die ist ja auch schon 5 Jahre alt.
Da sind sie doch?
Danke !
Seltsam, ich hatte natürlich vorher gesucht, aber wenn ich bei Google "Autoit+_WinAPI_LockFile" oder auch "Autoit+WinAPI LockFile" eingebe, kommt bei mir kein autoitscript-Hilfetreffer. Bei "Autoit+_WinAPI_FileInUse" hingegen schon !
Man sollte wohl doch besser direkt in der Hilfeübersicht suchen 
.
Gruß Musashi
Musashi, dann versuchs mal mit ner anständigen Suchmaschine statt mit dem Allerweltsgeschwür.
Aber wie dem auch sei, ich hatte früher schon mal daran rumexperimentiert und jetzt auch wieder.
Aber die Funktion tut nicht das was man erwarten würde . Die Datei wird nicht für jeden Zugriff gesperrt.
Man kann sie umschreiben, dann wird beim Speichern ein Hinweis gebracht, aber man kann die Datei ei8nfach löschen
und Windows lässt es klanglos zu.
Aber wenn z.B. ein Office_Teil von Ms das Ding sperrt, kann man sie nicht mal mehr ansehen.
Dieser Befehl hier ist mir ein grosses Rätsel.
Seltsam, ich hatte natürlich vorher gesucht, aber wenn ich bei Google "Autoit+_WinAPI_LockFile" oder auch "Autoit+WinAPI LockFile" eingebe, kommt bei mir kein autoitscript-Hilfetreffer. Bei "Autoit+_WinAPI_FileInUse" hingegen schon !
Du musst einfach nur nach "autoit _winapi_lockfile" suchen, du kannst in fast allen Fällen sogar das Keyword "autoit" weglassen, da die Nomenklatur der UDFs beinahe einzigartig ist und sich nur in seltenen Fällen mit anderen Funktionen überschneidet. Entweder kriegst du dann auch die AHK-Funktionen als Ausgabe und/oder die msdn-Seite dazu.
Musashi, dann versuchs mal mit ner anständigen Suchmaschine statt mit dem Allerweltsgeschwür.
Wenn man falsch sucht, dann braucht man auch nicht auf die richtigen Suchergebnisse zu warten, eine Suchmaschine ist nur so intelligent wie die Anfragen die man ihr schickt.
Du kannst das im BugTracker von autoitscript.com melden, such erstmal nach einem existierenden Ticket welches sich mit deinem Problem beschäftigt.
Wenn es keins gibt kannst du ein neues erstellen. Ich bin mir aber ziemlich sicher, dass es bereits dazu eins gibt und sie es, wenn es keins gibt, es nicht ändern werden.
Da gabs aber offenbar schon was dazu: https://www.autoitscript.com/trac/autoit/ticket/546
@ Tuxedo :
Ich bin zwar auch kein Freund der Google-Philosophie, aber das die Maschine selbst schlecht ist, kann man so nicht sagen.
Zum Thema :
Mit LockFile bin ich, zumindest auf die Schnelle, aber auch nicht zum Erfolg gekommen (kann an den Parametern liegen).
Wenn ich also völlig unbedarft den Code :
$sFilename = @ScriptDir & '\Test.txt'
$hFileOpen = FileOpen($sFilename, $FO_APPEND)
If _WinAPI_LockFile ($hFileOpen, 0, _WinAPI_GetFileSizeEx($hFileOpen)) Then ...
laufen lasse, bekomme ich den Fehler 6 = The handle is invalid
Möglicherweise muss man statt mit FileOpen auf _WinAPI_CreateFile etc. ausweichen.
Siehe auch Beitrag #3
Von Prozess auf einen Anderen Prozess zugreifen
Edit :
Trotzdem seltsam, dass die kombinierte Suche autoit+_winapi_lockfile fehlschlägt, autoit _winapi_lockfile aber nicht.
Na ja, egal.
Edit 2 : Blödsinn meinerseits. Kombinierte Suche mit AND oder Leerzeichen, nicht + 
Gruß Musashi
Seltsam, ich hatte natürlich vorher gesucht, aber wenn ich bei Google "Autoit+_WinAPI_LockFile" oder auch "Autoit+WinAPI LockFile" eingebe, kommt bei mir kein autoitscript-Hilfetreffer. Bei "Autoit+_WinAPI_FileInUse" hingegen schon !
Das Plus-Zeichen wird von Google automatisch eingefügt.
Du kannst die Suchergebnisse auch stärker eingrenzen, indem du Google einfach sagt, dass du nur Ergebnisse haben willst, die auf AutoIt.de zu finden sind:
_WinAPI_LockFile site:autoit.de
_WinAPI_UnLockFile site:autoit.de
Aber die Funktion tut nicht das was man erwarten würde . Die Datei wird nicht für jeden Zugriff gesperrt.
Hier mal eine kleine Demo...
;-- TIME_STAMP 2017-11-24 13:30:30 v 0.1
#Region ;************ Includes ************
#Include <WinAPI.au3>
#include <WinAPIFiles.au3>
#EndRegion ;************ Includes ************
If Not HotKeySet('{ESC}', '_Exit') Then Exit 1
Global $g_bLock = False, $g_hFile, $g_iOffset = 0, $g_iLength = 0
;~ _WinAPI_CreateFileEx ( $sFilePath, $iCreation [, $iAccess = 0 [, $iShare = 0 [, $iFlagsAndAttributes = 0 [, $tSecurity = 0 [, $hTemplate = 0]]]]] )
Global $iCreation = $OPEN_EXISTING, $iAccess = $GENERIC_READ, $iShare = $FILE_SHARE_DELETE
$g_hFile = _WinAPI_CreateFileEx(@ScriptFullPath, $iCreation, $iAccess, $iShare) ; [, $iFlagsAndAttributes = 0 [, $tSecurity = 0 [, $hTemplate = 0]]]]] )
If $g_hFile = -1 Then Exit -1
ConsoleWrite('$g_hFile = ' & $g_hFile & @CRLF)
If _WinAPI_LockFile($g_hFile, $g_iOffset, $g_iLength) Then
ConsoleWrite('! File ist now locked!' & @CRLF & _
'> Now you can even try to open, change or delete the file ... you will not succeed as long as the lock has not been released! ;-)' & @CRLF & _
'- Press ESC for UnLock File and Exit!' & @CRLF & @CRLF)
$g_bLock = True
; notepad can not open the file! ;-)
Local $iPID = Run('notepad.exe ' & @ScriptFullPath)
Else
ConsoleWrite("File can't locked!" & @CRLF & 'Error: ' & _WinAPI_GetLastError() & @CRLF & 'ErrorMessage: ' & _WinAPI_GetLastErrorMessage() & @CRLF)
Exit 2
EndIf
While 1
Sleep(1000)
WEnd
Func _Exit()
If $g_bLock = True Then _WinAPI_UnLockFile($g_hFile, $g_iOffset, $g_iLength)
ConsoleWrite('File ist unlocked!' & @CRLF)
_WinAPI_CloseHandle($g_hFile)
; notepad can open the file! ;-)
Run('notepad.exe ' & @ScriptFullPath)
Exit
EndFuncDann hat man es "schlampig" umgesetzt
So manche Entscheidung des Development Team ist fragwürdig, leider ist AutoIt nicht Open-Source also können wir das als Forenprojekt nicht forken und selber weiterentwickeln.
Da hilft nur Symptome bekämpfen (UDFs entwickeln die das richtige machen) und weiter, außer man macht sich die Mühe einen eigenen Interpreter zu schreiben (vielleicht sogar einen Compiler bzw. Übersetzer zu C/C++ o. ä. und dann compilen). Da gabs auch schon Ansätze dazu, siehe AutoItC.
Hallo Peter S. Taler,
Sondern darum, dass ein File, das vorhanden ist, geöffnet ist (zum Schreiben) gelöscht werden kann via explorer. Leg ein file Text.txt an. öffne es in Autoit ruf einen MSGbox auf - nimm den Explorer und lösch das text.txt - Das dürfte nach meiner Auffassung nicht funktionieren - tut es aber !
Öffne die txt doch mal mit dem Notepad oder einem anderen Editor und lösche die Datei. Klappt auch..
Eigentlich sehe ich da kein Problem oder Fehler..
Eigentlich sehe ich da kein Problem oder Fehler..
Ein Fehler ist es sicher nicht. Es fehlt lediglich eine Option bei FileOpen, um einen Zugriff von anderen Programmen zu verhinden, solange die Datei geöffnet ist. Wie es geht, habe ich in meinem Beispiel in Post #14 gezeigt.
Öffne die txt doch mal mit dem Notepad oder einem anderen Editor und lösche die Datei. Klappt auch..
Das liegt aber daran, dass Notepad die Datei vollständig einliest, somit ist kein Lock auf die Datei notwendig. Speichert man, so wird die Datei neu geöffnet.
Es findet also kein Streaming in die Datei statt.
Es stört Dich hoffentlich nicht, dass ich deinen Thread noch etwas quäle, gehört ja zu Thema .
Bitnugger : Danke für das Skript 
Was mich allerdings noch etwas irritiert :
1. Parameter $g_iLength :
$g_hFile = _WinAPI_CreateFileEx(@ScriptFullPath, $iCreation, $iAccess, $iShare)
Lt. Hilfe liefert @extended von _WinAPI_CreateFileEx ja einen Errorcode (_WinAPI_GetLastError())
Dieser Errorcode wird nun $g_iLength zugewiesen.
_WinAPI_LockFile erwartet als 3.Parameter :
: $iLength = The length of the byte range to be locked.
==> If _WinAPI_LockFile($g_hFile, $g_iOffset, $g_iLength) Then ...
Warum ist ein Errorcode (im Erfolgsfall=0) der Parameter der Wahl für die 'length of the byte range' ?
(Anmerkung : Man kann mit _WinAPI_LockFile auch Bereiche innerhalb einer Datei sperren)
Wäre _WinAPI_GetFileSizeEx($g_hFile), also der gesamte Bereich, nicht trotzdem geeigneter ?
Da es funktioniert, scheint ein teilweises Lock (hier sogar nur 0) aber wohl auszureichen.
2. Filehandle ist nicht gleich Filehandle !?
Schreibt man z.B. :
Global $g_hFile2 = FileOpen(@ScriptFullPath)
ConsoleWrite('GetFileSizeEx = ' & _WinAPI_GetFileSizeEx($g_hFile2) & @CRLF)
ConsoleWrite('FileGetSize = ' & FileGetSize(@ScriptFullPath) & @CRLF)
FileClose($g_hFile2)
dann erhält man als Konsolenausgabe :
GetFileSizeEx1= -1
FileGetSize = 2899
==> _WinAPI_GetFileSizeEx($g_hFile2) schlägt, wenn man das Handle aus FileOpen verwendet, fehl.
Man kann die _WinAPI_... Funktionen wohl nicht mal eben so mit Funktionen wie FileOpen mischen, korrekt ?
P.S.
Ich hoffe, meine Fragen sind kein totaler Schwachsinn. Heute ist, mehr als üblich, mein 'zwei-linke-Gehirnhälften-Tag' 
Gruß Musashi
