FileCopy und FileExist Fehler unter Windows 10 Prof

    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

    Vielleicht benötigt dein Script ja ein "#RequireAdmin" um den Vorgang auszuführen


    Gesendet von iPhone mit Tapatalk

    Edit:

    Hab mir dein Script grade mal am PC angeschaut.
    Du hast zwar ein "#RequireAdmin" drin, aber das ist falsch.
    Dein sieht so aus:

    AutoIt
    #RequireAdmin = YES


    Es muss aber so aussehen:

    AutoIt
    #RequireAdmin

    LG

    Philip

    Einmal editiert, zuletzt von n00b-it (22. Oktober 2015 um 12:06)

    @grebph
    Falsch ist es nicht. Es ist zwar nicht nötig explizit = yes dahinter zu kritzeln aber der Effekt ist dennoch der selbe.

    @Converter
    Ein prinzipielles Win 10 Pro Problem wird es sicherlich nicht sein, da ich dies gerade auf einem Win 10 Pro versucht habe nachzuvollziehen.
    Es funktioniert alles wie es sollte.
    Die Datei wird gefunden, kann geöffnet werden und gelesen.
    Alles auch ohne Admin-Rechte.

    Klingt eigentlich wirklich eher nach einem Pfad-Problem.
    Statt den Pfad fest aus deinem String zu nehmen probiere mal stattdessen ein FileOpenDialog zum erzeugen des Pfades.
    Also am besten mal die Ausgabe von folgendem kleinen Skript posten:

    AutoIt
    $s_Path = FileOpenDialog("Test", "C:\Windows\Microsoft.NET\assembly\GAC_32\Microsoft.GroupPolicy.AdmTmplEditor", "Dll files (*.dll)")
ConsoleWrite(StringFormat("\n$s_Path: %s\nFileExists: %s\nFileOpen: %s\nFileGetAttrib: %s\nFileRead: %s ... etc.\n\n", $s_Path, FileExists($s_Path), FileOpen($s_Path), FileGetAttrib($s_Path), FileRead($s_Path, 20)))

    btw.: die 3 Auslassungspunkte in deinem Pfad - sind die bewusst reingemacht worden?

    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 ?

    Ich wiederhole mich einfach mal:
    Poste bitte die Ausgabe von folgendem Skript:

    AutoIt
    $s_Path = FileOpenDialog("Test", "C:\Windows\Microsoft.NET\assembly\GAC_32\Microsoft.GroupPolicy.AdmTmplEditor", "Dll files (*.dll)")
ConsoleWrite(StringFormat("\n$s_Path: %s\nFileExists: %s\nFileOpen: %s\nFileGetAttrib: %s\nFileRead: %s ... etc.\n\n", $s_Path, FileExists($s_Path), FileOpen($s_Path), FileGetAttrib($s_Path), FileRead($s_Path, 20)))

    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

    Gesteinigt wird man hier nicht - vorrausgesetzt man setzt den Beitrag auf gelöst :)

    Hinweise auf Suchmaschinen finde ich überflüssig - wer fragt hat es nicht gefunden oder nicht verstanden. Die Antwort gibt sich oftmals schneller als der Hinweis auf Dr. Goggle & Co.

    Ab 19-10-22 ergänzt um:

    Die Welt wird nicht bedroht von den Menschen, die böse sind, sondern von denen, die das Böse zulassen. (Albert Einstein)