Ja das war es, besten Dank,

für die schnelle Hilfe.

Ein Frage habe ich noch, wo finde ich die Infos zu der

Option " #AutoIt3Wrapper_UseX64="

vieliecht bin ich ja schon blind vor lauter Hilfe-Files lesen, ich finde nichts.

Ja danke für den Hinweis,

ich habe den Vorschlag der in dem Link steht ausprobiert

#include <WinAPIFiles.au3>

_WinAPI_Wow64EnableWow64FsRedirection ( True)

Ich kann True oder auch False eingeben, das ergebniss ist

immer gleich es kommt "ProgramFiles(x86)" heraus.

Und wenn ich mit EnvGet ("ProgramFiles") den Wert einer Umgebungsvariable

auslese, sollte eigentlich immer das rauskommen was drin steht ! oder sehe ich das falsch ?

Nein geht nicht so wie erwartet

Ich bekomme jetzt zwar "Program Files" , aber wenn ich mit

EnvGet ("ProgramFiles(x86)") aufrufe kommt ebenfalls "Program Files" raus

Siehe

#RequireAdmin = YES

AutoItSetOption ("MustDeclareVars", 1)
#AutoIt3Wrapper_UseX64=Y

Local $p_Prgx64 = ""
Local $p_Prgx86 = ""

If Not @AutoItX64 And @OSArch = 'x64' Then
    $p_Prgx64 = EnvGet ("ProgramFiles")
    $p_Prgx86 = EnvGet ("ProgramFiles(x86)")
Else
    $p_Prgx64 = EnvGet ("ProgramFiles")
    $p_Prgx86 = EnvGet ("ProgramFiles")
EndIf

MsgBox(64,"Dir Info","Ihr System ist = " & @OSArch & "   Windows = " & @OSVersion & @CRLF & "Makro @ProgramFilesDir = " & @ProgramFilesDir & _
        @CRLF & "EnvGet ProgramFiles = " & EnvGet ("ProgramFiles") & @CRLF & _
        @CRLF & "Variable p_Prgx64 = " & $p_Prgx64 & @CRLF & "Variable p_Prgx86 = " & $p_Prgx86)

Hallo,

ich habe mir die aktuellt Autoit-Version von diesem Forum heruntergeladen,

und bei mir installiert, was auch ohne Problem klappt.

Mein System ist Windows 7 in der 64 Bit Version, und Autoit nutze ich in der 32 oder auch x86 Version.

Wenn ich das Autoit Makro @ProgramFilesDir abfrage bekomme ich als Verzeichniss immer "Program Files (x86)" angegeben.

Wenn ich mit EnvGet ("ProgramFiles") abfrage bekomme ich ebenfalls "Program Files (x86)" wieder.

Wenn ich mit der CMD set eingebe bekomme ich das was man erwartet "Program Files"

Mache ich was falsch oder ist das tatsächlich ein Bug ?

Hallo,

ich weiss nicht genau wo ich dieses Thema einstellen soll,

aber es gibt seit 2 Februar 2018 auf der orginal Autoit Website

ein neues Relaese.

AutoIt v3.3.14.3

Dieses Release hat viele Fixes, es lohnt sich.

Warum erscheint dieses Release noch nicht hier ?

Hallo,

und besten dank für die anregungen, hat mir schon gut geholfen.

Was ich möchte ist eigentlich trivial, hab ich zumindestens gedacht.
Ich habe mir ein Autoit Script geschrieben das bei jedem Rechnerstart automatisch die Benutzer bzw. User Files die im
"User" VZ von Windows liegen sichert.Also simpel gesagt Kopiere von A nach B. Das geht auch, nur beim zurückspielen wollen einige Programme nicht
richtig laufen wegen falschen Rechten, vor allem dann nicht wenn ich sie von mein PC auf mein Laptop kopiere.
Das liegt eindeutig an den Rechten und den Besitz von den Dateien emperisch ausprobiert.

Ich muss also beim kopieren der Files den Besitzer ausmachen, sowie alle eingetragenen User sowie die dazugehörigen Rechte.
Es reicht wenn ich weiss ob volle Zugriffsrechte ,oder nur lesen, oder nur lesen und ausführen für jeden Nutzer eingestellt ist.

Im Prinzip das gleiche, als wenn ich mit der Maus auf ein File zum selektieren klicke und dann mit der rechten Maustaste unter Eigenschaften
anklicke, dann auf den Tab für Sicherheit gehe. Dort werden alle User die die Datei nutzen können mit den dazugehörigen Rechten angezeigt.
Beim TAB Sicherheit gibt es noch ein Buttom Erweitert wo ich den Besitzer ausfindig machen kann.

Hallo,

vielen Dank schon mal für die Vorschläge,

die Function um Com-Fehler auszuwerten kannte ich noch nicht, funktioniert tadellos.
Aber ich bekomme jetzt eine Fehlermeldung die ich mir schon fasst gedacht habe, nämlich "Mitglied nicht gefunden".
Das ist ja zumindestens ein aussage mit der man was anfangen kann.

In der Func ReadFileOwner_Alles mache ich irgndetwas falsch, wahrscheinlich in dieser Zeile,

"$intRetVal = $Obj_Owner_of_File.GetSecurityDescriptor($Obj_Owner)" meine vermutung.

Ich habe schon das Web stundenlang durchsucht, vieles gefunden aber auch immer mehr irritiert, weil man viele
Examples findet die auch ungefähr das gleiche Thema behandeln aber alle ganz unterschiedlich umgesetzt sind.
Viele diese Examples kann ich leider auch nicht ausprobieren weil es oft um Netzwerke und Administration geht.
Privat für mein kleines Home-Netzwerk nicht zugebrauchen.

Das Tool Scriptomatic hatte ich auch schon gefunden und ausprobiert, leider stürzt es bei anwahl einiger Funktionen
einfach ohne jegliche ankündigung ab.

Eine noch einfache Frage
Ich habe gesehen das mein Code nicht als solcher aussieht wie ihn eingestellt habe, es sollte so aussehen wie von
Ahnungslos, weisser Hintergrund mit Zeilennumerierung wie geht das ?

Hallo ich habe ein riesenproblem mit WMI Abfragen.

Ich möchte die eigenschaften von Files und Directorys abfragen, das ergebniss soll in etwa so sein als wenn ich unter Windows ein File selektiere und unter Eigenschaft den
Reiter Sicherheit anklicke. Unter Gruppen und Benutzernamen bekomme ich alle User und Gruppen die einer Datei oder einem Directory zugewiesen sind incl. die Rechte.
So etwas brauche ich. Den Eigentümer bekomme ich auch mittels WMI-Abfrage raus, allerdings nicht die anderen Parameter und auch nicht alle Benutzer.
Irgendwie mache ich was falsch nur weiss ich nicht was.

Die Function ReadFileOwner_Single geht wie vorgesehen
Die Function ReadFileOwner_Alles gibt mir nur einen leeren String zurück aber es kommt keine Fehlermeldung

Währe schön wenn einer ein Tipp hätte Irgenwie habe ich den durchblick verloren

;Autoitscript

$wbemFlagReturnImmediately = 0x10
Local $File_Pfad = @WindowsDir & "\hh.exe" ; Nur zum Test, nur Lesezugriff

; impersonationLevel = impersonate ist bevorzugte Standardvorgabe MS
Local $Obj_WMIService = ObjGet("winmgmts:{impersonationLevel = impersonate}!\\" & @ComputerName & "\root\cimv2")

ReadFileOwner_Single ($File_Pfad) ; TEST ein Wert auslesen
ReadFileOwner_Alles ($File_Pfad) ; TEST alles auslesen was das Objekt hergibt

Func ReadFileOwner_Single ($Obj_CheckFile)
Dim $Obj_Owner
$Obj_Owner_of_File = $Obj_WMIService.Get("Win32_LogicalFileSecuritySetting='" & $Obj_CheckFile & "'")
$intRetVal = $Obj_Owner_of_File.GetSecurityDescriptor($Obj_Owner)

If (IsObj($Obj_WMIService)) And (Not @error) Then ; Ist das Objekt $Obj_WMIService ein bekannetes Objekt
MsgBox (0, "ReadFileOwner", "Owner: " & $Obj_Owner.Owner.Domain & "\" & $Obj_Owner.Owner.Name)
Else
Msgbox(0,"WMI Output","Keine WMI Objects gefunden: " & "Win32_LogicalFileSecuritySetting" )
Endif

EndFunc

Func ReadFileOwner_Alles ($Obj_CheckFile)
Local $a_Text = ""
Local $Obj_Properties = ""
Dim $Obj_SecureRead

$Obj_Owner_of_File = $Obj_WMIService.Get("Win32_LogicalFileSecuritySetting='" & $Obj_CheckFile & "'")
$intRetVal = $Obj_Owner_of_File.GetSecurityDescriptor($Obj_SecureRead)

If (IsObj($Obj_WMIService)) And (Not @error) Then ; Ist das Objekt $Obj_WMIService ein bekannetes Objekt

ConsoleWrite ("Func ReadFileOwner_Alles nach IsObj Abfrage ")

For $Obj_Properties In $Obj_SecureRead
$a_Text = 'Description: ' & $Obj_Properties.Description & @CRLF
$a_Text = $a_Text & 'Caption: ' & $Obj_Properties.Caption & @CRLF
$a_Text = $a_Text & 'OwnerPermissions: ' & $Obj_Properties.OwnerPermissions & @CRLF
$a_Text = $a_Text &'ControlFlags ' & $Obj_Properties.ControlFlags & @CRLF
$a_Text = $a_Text & 'Path: ' & $Obj_Properties.Path & @CRLF
$a_Text = $a_Text &'SettingID: ' & $Obj_Properties.SettingID & @CRLF
Next

MsgBox (0,"TEST Komplett", $a_Text)
EndIf
EndFunc

Hallo, liebe Forenmitglieder und besonders AspirinJunkie

Ihr dürft mir Steinigen aber hoffentlich nur Sinnlich.

Mir ist ein saublöder Fehler unterlaufen, allerdings weiss ich nicht wie.
Aus mir jetzt nicht mehr nachvoll ziehbaren Gründen habe ich wohl die orginal Windows 10 Verzeichnisse wo es zu diesem
Fehler kam im Namen Verändert. Überall wo orginal "_" Unterstriche" wahren haben sich jede menge "." Punkte zusätzlich
eingeschlichen. Ich weiss nur nicht warum. Nur komisch das Windows lief einwandfrei. Nicht mal in der Ereignissanzeige wahren Einträge.

Ist mir in dieser langen Nacht erst aufgefallen als ich aus reiner Vorsicht ein Sicherungspunkt der virtuellen Maschine zurückgespielt
hatte. Dies habe ich gemacht nachdem ich bei Microsoft MSDN https://msdn.microsoft.com/de-de/library/…7(v=vs.85).aspx
stark mein Englisch verbessert habe und einige Ungereimtheiten in den Verzeichnisspfaden erkannt hatte.

Die Seite ist im übrigen sehr Empfelenswert, aber trockner Stoff.

Mein Script funktioniert nach zurückspielen der Sicherung einwandfrei.
Ich habe wohl einen blinden Alarm ausgelöst.

Entschuldigung

Danke für die Anworten,

das Test-Script was ich mit verlinkt habe ist sehr klein und extra einfach gehalten.
Einfach mal runterladen.

Das Scipt Test-Script sowie das richtige komplette Script enhält natürlich #RequireAdmin = YES.

Ich habe sogar, natürlich nach einem Backup alle Files die ich kopieren möchte an mich gerissen.
Sprich ich habe den Besitzer der Dateien dahin geändert das sie alle zur Gruppe der Administratoren
gehören, danach habe ich die Rechte auf vollzugriff gesetzt. Leider ohne erfolg.
Nach dem vielen ausprobieren schätze ich eher das es nicht mit den Rechten zu tun hat.
Wie ich schon oben beschrieben hatte kann ich die im Script genannte Datei ja ohne Probleme
mit dem Windows Explorer kopieren. Und unter Windows 7 funktioniert es ja auch.

Ich vermute eher das sich was in der WinApi oder sowas ähnliches verändert hat ?

Hallo, ich habe unter Windows 10 Professional mit den beiden

Befehlen "FileExists,FileCopy und wahrscheinlich auch DirCopy" Probleme, "Bestimmte Windows Dateien zu kopieren".
Ganz einfach gesagt je nach dem was ich kopieren möchte, wird mir z.b. bei
Ausführung von FileExist gemeldet das File sei nicht da, obwohl es vorhanden ist, Filecopy kopiert dann natürlich auch nicht.
Der Fehler tritt auch mit maximalen Rechten für den Benutzer und Eigentümer dieser Datei auf.

Da ich den Quell-Code unter Windows 7 Prof. schreibe und das Proggi für Windows 10 sein soll, habe ich mir mit Virtual-Box
ein Windows 10 Prof erstellt und dort das Prog ausprobiert weil sich die Verzeichniss Structur von Window dort zum teil verändert hat.

Das eigentlich merkwürdige kommt aber jetzt.
Da ich unter Windows 10 kein erfolg habe, habe ich kurzerhand den kompletten Verzeichnisspfad incl. der Datei mit dem Explorer
aus der Virtuellen Maschine herauskopiert und in mein laufendes Windows 7 exakt an der gleichen Stell reinkopiert.

Dabei kam schon mal die feststellung das das Verzeichniss sowie die eigentliche Datei unter Windows 10 nicht geöffnet war und
auch von den Rechten her nicht blockiert ist, sie lies sich ohne Problem kopieren und in Windows 7 wieder einfügen.

Dann habe ich mit dem selben Test-Programm was unter Windows 10 nicht geht, unter Windows 7 probiert.
Unter Windows 7 funktioniert der kopiervorgang einwandfrei, und der Witz ist, auch wenn ich die Option "#AutoIt3Wrapper_UseX64 = YES"
nicht verwende obwohl ein 64 Bit System habe geht auch dort der Kopiervorgang ?

Im übrigen funktioniert der xcopy Befehl nur bei diesem Verzeichniss und Datei unter Windows 10 auch nicht.
Ansonsten kann ich noch sagen das die Datei incl. Verzeichniss sich mit den Windows Explorer und auch noch 2 anderen
Datei-Managern ganz normal suchen und kopieren lässt.

Die Datei die ich hier Poste ist nur eine reine Test-Datei nicht wundern.
Ich verwende sie ausschliesslich zum Testen, das VZ und die Datei sind natürlich so wie sie tatsächlich unter Windows 10 vorhanden sind .

Nach dem ganzen Testen sind es fast so aus als habe Microsoft sich in Windows 10 mal wieder was neues einfallen lassen.

Der reine Pfad ist im übrigen 143 Zeich lang und sieht so aus

"C:\Windows\Microsoft.NET\assembly\GAC_32\Microsoft.GroupPolicy.AdmTmplEditor\v4._1...__31bf3856ad364e35\Microsoft.GroupPolicy.AdmTmplEditor.dll'

Vieleicht kennt ja noch eine Lösung oder elegante Umgehung ?

TEST.au3