FileInstall Funktion funktioniert nicht (immer) auf Windows 7 32 Bit?

  • Hallo,

    ich habe ein etwas seltsames Problem hier.

    Wir nutzen AutoIt um Software zu installieren. Das klappt eigentlich auch schon seit Jahren recht gut und zuverlässig. Allerdings haben wir mit ein paar Paketen das Problem, dass die zu installierenden Sourcedateien unter Windows 7 32 Bit nicht kopiert werden bzw. nicht immer kopiert werden. Unter Windows 7 64 Bit oder Windows 10 64 Bit tritt das Problem nicht auf.

    Beim Kompilieren befinden sich die Sourcen in einem Unterverzeichnis des Scriptes und werden auch eingebunden (ansonsten würden sie ja auch unter W7/W10 64 Bit nicht da sein...) und beim Starten des Pakets sollten sie in das existierende Verzeichnis C:\temp\packages\ kopiert werden. Die Datei "Source.7z" ist etwas über 600 MB groß.

    Code
    $FCIA_WorkDir = C:\temp\packages\
    . . .
    FileInstall(".\Source\7za.exe", $FCIA_WorkDir, 1)
    FileInstall(".\Source\Source.7z", $FCIA_WorkDir, 1)
    FileInstall(".\Source\Config.xml", $FCIA_WorkDir, 1)
    . . .

    Zur Sicherheit haben wir den Parameter für den Target-Pfad aus dem obigen Beispiel-Source schon durch den eigentlichen Pfad ersetzt, den Virenchecker deaktiviert und sogar deinstalliert. Das komplette Paket unter W7 32 Bit als 32 Bit EXE kompiliert, um sicher zu gehen keine 64 Bit DLL eingebunden zu haben. Mit einem frisches W7 32 ohne jegliche Patche den Test gemacht, aber alles erfolglos.

    (ach ja, den Source-Pfad habe ich auch schon vollständig angegeben, nur um sicher zu gehen, dass es mit den relativen Pfaden kein Problem gibt)

    Jeweils haben wir die erstellte Version parallel auf einem 64 Bit System ohne Probleme installieren können, d. h. dort konnten wir sehen, wie die Dateien kopiert wurden.

    Wenn wir jetzt die große Datei "Source.7z" nicht einbinden, funktioniert das Kopieren der übrigen Dateien. Die Datei "Source.7z" ist aber auch nicht defekt, da sie sich ohne Problem auf Kommandozeilen-Ebene kopieren und entpacken läßt. Wir haben auch schon andere, unregistrierte Dateiendungen ausprobiert und andere Packgrade, um das Kopieren zu testen, ohne Erfolg.

    Kann es sein, das FileInstall unter Windows 7 32 Bit Probleme mit Dateien ab einer Größe von 500 MB hat? Wir nutzen die letzte AutoIt Version (keine Beta).

    Bis vor zwei AutoIt Versionen kannten wir diese Probleme gar nicht, auch dort hatten wir schon Pakete im Einsatz, die weitaus größere Sourcedateien eingebunden hatten ... wir mußten nur wegen W8/W10 auf die neueren Versionen wechseln...

    Vielleicht hat ja jemand von Euch eine Idee was der Grund sein könnte...

    Mit freundlichen Grüßen

    Axel

    There exist 10 different kind of people on earth.
    Those who understand binary, and those who don't.

  • Hallo ahe

    zu deinem Problem kann ich direkt gar keine Aussage treffen. Ich hätte nur eine alternative Vorgehensweise vorzuschlagen. Statt per FileInstall bindest du die Datei(en) per Base64 String ein. UEZ hat hier einen Generator bereitgestellt. File to Base64 String Code Generator v1.20 Build 2015-01-20

    (Du musst im Code die maximale Dateigröße ändern/deaktivieren).

    Ich nutze das sehr gerne. Ich kann dir zwar nicht garantieren, dass es nun immer die Datei schreibt, weil ich das Problem ja nicht kenne (vllt. mangelnde Schreibrechte im gewünschten Verzeichnis oder was auch immer). Allerdings machst du dann selbst den Aufruf zum Erstellen der Datei. Das gibt dir die Möglichkeit Vorbereitungen zu treffen (bspw. Verzeichnis erstellen/Schreibrechte prüfen) und eigene Fehlerprüfungen/-meldungen zu implementieren.

    EDIT: Nach etwas überlegen, weiß ich gar nicht, ob das wirklich bei so großen Paketen praktikabel ist. So groß waren meine integrierten Pakete noch nie.

    Grüße autoiter

    Einmal editiert, zuletzt von autoiter (15. November 2017 um 18:06)

  • EDIT: Nach etwas überlegen, weiß ich gar nicht, ob das wirklich bei so großen Paketen praktikabel ist. So groß waren meine integrierten Pakete noch nie.

    Ich weiß nicht ob das überhaupt sinnvoll wäre, wenn AutoIt den String dann als ganzes liest, dann landen im Arbeitsspeicher 600 MB Dateien.

    FileInstall schafft das ganze ohne den RAM zu überladen glaube ich.

  • Hallo ihr,

    ein Test ist mir noch eingefallen, den ich noch nicht ausprobiert hatte. In der Vergangenheit hatten wir etwas größere SW Pakete zu packen, allerdings haben wir da noch kein AutoIt verwendet, sondern noch gute alte Batches... Da es da doch etwas Probleme mit der Größe einer einzelnen Datei gab, haben wir diese per 7zip in kleinere Dateien aufgeteilt, diese auf das Ziel kopiert und anschließend über 7zip expandiert (oder war das noch pkunzip?).

    Ich denke wir versuchen das jetzt erst einmal, nur blöd, wenn man anstelle von einer Datei dann 20 hat...

    Eine weitere Alternative ist, wenn auch nicht so schön unabhängig vom Netz, wenn man die Installation aufteilt. Ein kleines Paket für die Installationslogik, welches dann die Source-Datei(en) vom Netzshare zieht. Dafür muss man natürlich von überall den Share erreichen und die Berechtigungen müssen entsprechend gesetzt sein.

    Funktioniert sogar, nur dann habe ich nicht mehr beide Teile zusammen und könnte meinem Installationsscript einfach einen neuen Source unterschieben (hätte auch seinen Charme, aber aus Sicherheitsgründen...). Um dies zu verhindern müßte über diesen Source ein Hash gebildet werden, der dann im Installationsscript abgefragt wird...

    Mmh, eigentlich eine Idee, sollte auch nicht so schwierig zu implementieren sein, nur wie lange dauert es einen Hash von einer großen Datei auf einem Netzwerkshare zu prüfen? Muss ja jedes Mal beim Start des Pakets über das Netz errechnet und anschließend (das sollte dann schnell gehen) mit dem Wert im Skript verglichen werden.

    Ich denke ich probiere erst einmal das Aufsplitten... und melde mich wieder.

    mfg

    Axel

    There exist 10 different kind of people on earth.
    Those who understand binary, and those who don't.

  • Hallo ahe !

    Ich habe mit meinem Vorschlag gewartet, falls bis jetzt doch noch die 'perfekte' Antwort gekommen wäre.

    Da im Forum, z.B. bei Geschwindigkeitsproblemen, häufig auf externe Lösungen wie C oder FreeBasic zurückgegriffen wird, stellt mein Vorschlag (hoffentlich) keine Verletzung der Forenregeln dar (falls doch, bitte mitteilen).

    Zur Sache :

    Könntest Du dich mit dem Gedanken anfreunden, den OpenSource-Installer Inno Setup ins Boot zu holen ?

    Ich habe damit einige Erfahrung, und würde Dir bei der Erstellung eines Inno-Skriptes helfen.

    Das Setup (silent oder mit GUI) ließe sich aus einem AutoIt-Programm aufrufen, oder bei Bedarf auch stand-alone starten.

    Das Ganze läuft selbstverständlich unter den Regeln der Rubrik Hilfe & Unterstützung , d.h. uneigennützig :)!

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

    Einmal editiert, zuletzt von Musashi (15. November 2017 um 23:22) aus folgendem Grund: erweitert

  • Hallo Musashi,

    danke, wir hatten auch schon überlegt, ob wir einen Installer verwenden, ob jetzt Inno Setup oder etwas kommerzielles.

    Allerdings kam jedes Mal die Fragen auf, können wir daraus Meldungen verschicken, kann das Tool auch Logs schreiben, wie wir es wollen, etc. und v. a. was kostet das Tool an Geld, Zeit für die Einarbeitung, Schulung, etc.

    Daher sind wir bei AutoIt geblieben... hat halt viele Vorteile :) und wir nutzen alle die gleiche Version + eine eigene Funktions-Lib... (macht das Debuggen einfacher)

    Aber ich werfe das Thema noch mal in unserem Meeting in die Runde, wenn wir keine Lösung für die großen Pakete finden...

    Meine Tests mit dem Aufsplitten der Source-Datei in mehrere kleine Dateien hat im Übrigen nix gebracht, sobald ich über 500 MB komme, war es das. (ist auch egal, was das für Dateien sind).

    Wenn ich nur wüsste, warum das jetzt passiert, wir haben schließlich in den vergangenen Jahren schon deutlich größere Pakete erstellt die auf W7 32 Bit keine Probleme machen... :(


    mfg

    Axel

    There exist 10 different kind of people on earth.
    Those who understand binary, and those who don't.

  • Hallo Musashi,


    danke, wir hatten auch schon überlegt, ob wir einen Installer verwenden, ob jetzt Inno Setup oder etwas kommerzielles.


    Allerdings kam jedes Mal die Fragen auf, können wir daraus Meldungen verschicken, kann das Tool auch Logs schreiben, wie wir es wollen, etc. und v. a. was kostet das Tool an Geld, Zeit für die Einarbeitung, Schulung, etc.

    Daher sind wir bei AutoIt geblieben... hat halt viele Vorteile und wir nutzen alle die gleiche Version + eine eigene Funktions-Lib... (macht das Debuggen einfacher)

    Aber ich werfe das Thema noch mal in unserem Meeting in die Runde, wenn wir keine Lösung für die großen Pakete finden...

    Hallo ahe !

    Es geht auch nicht darum, dass Du AutoIt verlassen sollst , *** bewahre :).

    (für *** mag jeder sein religiöses oder weltliches Bekenntnis einsetzen)

    Inno Setup ist, auch für kommerzielle Zwecke kostenlos, ohne Hintertürchen. Die Installation verläuft ähnlich zu AutoIt, d.h. man erhält einen Editor mit 'Kompilerfunktion'. Das Programm selbst ist ein professionelles Tool, hat also einen großen Funktionsumfang und eine steile Lernkurve. Du wirst aber wahrscheinlich nur einen Bruchteil davon brauchen.

    Inno bietet für Standardoperationen bereits vorgefertigte Eventseiten an. Dafür könnte ich Dir ein Skript erstellen. Sofern sich Erweiterungen z.B. nur auf das Hinzufügen/Ändern von Dateien beschränken, kannst Du sie danach leicht selbst ausführen.

    Dazu müsste ich aber mehr Details wissen. Um das Forum nicht mit themenfremden Inhalten zu belasten, starte einfach eine Konversation.


    Da bei Dir offenbar das Einbinden großer Dateien mit FileInstall ein Problem ist, wäre die Teilauslagerung in ein externes Setup oder eine externen Zip ja eh erforderlich. Dieses File könntest Du mitliefern und über AutoIt starten.

    Interessanterweise habe ich im Netz keine klare Begrenzungsregel gefunden, also z.B. : "eingebundene Dateien dürfen maximal xxx MB groß sein" oder Ähnliches. Allein einen Hinweis, man sollte die interne UPX Komprimierung ausschalten (Default=An), also #AutoIt3Wrapper_UseUpx = N , da hier angeblich viel im Speicher passiert. Dass war aber eine reine Vermutung, und kommt nicht von mir.

    Die Alternative von alpines , einfach eine ältere Version von AutoIt zu verwenden, ist aber auch ein gangbarer Weg, und zudem mikroinvasiv.

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Mmh, 3.3.8 habe ich jetzt noch nicht probiert. Ich teste das mal auf einem nackten W7... aber wohl erst morgen... jetzt heisst es erst einmal sich ausreichend mit Kaffee für die kommenden Telkos versorgen... :)

    There exist 10 different kind of people on earth.
    Those who understand binary, and those who don't.

  • Ich würde wie hier schon vorgeschlagen wurde komplett auf Fileinstall verzichten und alle Setupdateien oder was auch immer du auf den Zielsystemen entpacken willst über Netzlaufwerke bereitstellen.

    Das hat extrem viele Vorteile:

    - Ein zentraler Speicherort für 32/64bit spezifische Daten

    - Unter Microsoft Serverbetriebssystemen evtl. sogar ein aktives Monitoring über Zugriffe und Veränderungen des Verzeichnisses (siehe Sicherheitsbedenken)

    - Einfache Erweiterung oder Erneuerung der Datendateien z.B. neue Programmversionen (sofern du Setups ausrollst)

    - Kein permanentes Neukompilieren deines Scriptes bei Änderungen der Datendateien

    Sicherheitsbedenken gibt es eigentlich keine, sofern du für den genutzten Netzwerkpfad lediglich einen Account mit Leserechten im Script hinterlegst. Warum sollte jemand unbefugtes unbemerkt die Datendateien ändern können? Irgendwo liegen ja auch deine kompilierten Scripte, welche letztlich auf den Clients landen... ein Angreifer könnte genausogut das komplette Script durch sein eigenes ersetzen.

    Aber grundsätzlich wäre es schon interessant zu wissen warum Fileinstall auf 32bit Systemen ein anderes Verhalten als auf 64bit Systemen zeigt. Ich könnte mir vorstellen, dass hier RAM Limitierung das Problem verursachen. Unter 32bit Systemen ist der maximale Speicher einer Anwendung auf 2GB beschränkt. Vermutlich haben die Clients auch eher weniger Speicher als die 64bit Clients, grundlos setzt man ja wohl heutzutage kein 32bit Windows mehr ein. Kannst ja mal prüfen ob es bei gleichen RAM Bedingungen auch unter 64bit zum Fehler kommt und allgemein mal per Taskmanager prüfen wie der RAM Verbrauch des Scriptes kurz nach der Ausführung ausschaut.

  • Sorry für meine späte Antwort, war viel unterwegs in letzter Zeit... aber habe das Thema nie aus den Augen verloren.

    Die Ideen mit dem zentralen Speichern der Dateien und dem Starten eines kleinen Installationsskripts hatten wir auch schon, wurde auch z. T. schon umgesetzt. Leider haben wir das Problem, dass wir mehrere Standorte mit rel. schlechter Verbindung zum zentralen Server haben. D. h. wir verwenden sog. Repositories an diesen Standorten und müssen daher dort die Pakete synchron halten. Bei ein paar hundert oder tausenden Dateien, kein so großes Problem. Wir sprechen hier aber leider über ein paar hundert tausend Dateien... (wir haben viele umfangreiche Software Pakete... div. Office Versionen, SAP, etc.).

    Ein Austausch des Skriptes ist nicht so einfach für einen Angreifer, da er im zentralen System dafür den Hash der Datei in einer Datenbank ändern müßte. Wenn er das geschafft hat, haben wir, glaube ich, ganz andere Sorgen :)

    Wir haben inzwischen noch ein paar Dinge herausgefunden, die uns noch etwas mehr irritieren.

    Wir testen und installieren die SW mit "Local System" Rechten (die SW Verteilung läuft als lokaler Dienst mit lokalen System rechten, daher). Dies funktioniert bei nahezu jeder Software ohne Probleme (klar, man muss etwas bei den Registry-Keys tricksen).

    Nachdem jetzt ein Kollege meldete, er hätte keinerlei Probleme mit FileInstall und großen Dateien, haben wir analysiert, wie er testet und mussten feststellen, dass er die EXE mit "Run as admin" startet. Ein einfacher Test mit meinem kleinen FileInstall Skript brachte die Erkenntnis, es geht als lokaler Admin, nicht aber als Local System... ?!?

    Es liegt also wohl nicht am RAM (wir reden seit Jahren darüber 32 Bit zu kicken ...), sondern eher an etwas Anderem.

    Zur Zeit versuche ich mich an der "Res Add File" Funktondes Wrappers: #AutoIt3Wrapper_Res_File_Add="dateiname.zip", RT_RCDATA mit der Funktion _FileInstallFromResource

    Komme aber nicht so recht weiter. Ich sehe via ProcMon, wie im Speicher etwas hochgezählt wird (was der Dateigröße entspricht), aber es wird nirgendwo etwas abgelegt.

    Melde mich wieder, wenn ich eine Lösung habe...

    .

    There exist 10 different kind of people on earth.
    Those who understand binary, and those who don't.

  • Hallo,

    ich wollte doch noch eine Lösung übermitteln, wenn gefunden...

    Es hat zwar etwas länger gedauert, dafür funktioniert es jetzt auch schon seit ein paar Wochen mit verschiedenen, großen Paketen (auch über 1.2 GB).

    Wir haben unsere Installationsdateien in kleinere Häppchen unterteilt und binden sie jetzt, wie auch oben schon beschrieben, über den Wrapper als Resource File ein:

    Code
    #AutoIt3Wrapper_Res_SaveSource=y
    #AutoIt3Wrapper_Res_File_Add=.\Source\Source.7z.001, 10, Source.7z.001
    #AutoIt3Wrapper_Res_File_Add=.\Source\Source.7z.002, 10, Source.7z.002
    #AutoIt3Wrapper_Res_File_Add=.\Source\Source.7z.003, 10, Source.7z.003
    #AutoIt3Wrapper_Res_File_Add=.\Source\Source.7z.004, 10, Source.7z.004

    Eingebunden haben wir für die Verarbeitung die resources.au3 aus einem Forum (welches weiss ich leider nicht, hat mein Kollege "gefunden", aber ProgAndy hat da wohl auch seine Finger unterstützend mit im Spiel :-), siehe angehängte Datei)

    Mit der Funktion _ResourceSaveToFile aus der Lib können wir dann die Dateien speichern, um sie später expandieren und für das Setup nutzen zu können.

    Code
    _ResourceSaveToFile($FCIA_WorkDir & "Source.7z.001", "Source.7z.001")
    _ResourceSaveToFile($FCIA_WorkDir & "Source.7z.002", "Source.7z.002")
    _ResourceSaveToFile($FCIA_WorkDir & "Source.7z.003", "Source.7z.003")
    _ResourceSaveToFile($FCIA_WorkDir & "Source.7z.004", "Source.7z.004")


    Schönen Gruß

    Axel

  • Keine Ahnung... komisch ist nur, die Bitmap in einem Pic-Control anzeigen, oder die Dimensionen auslesen, geht... nur eben nicht Speichern.... auch nicht mit...

    AutoIt
    ; $sResNameOrID = $RT_BITMAP
    ; ...
    Local $hMod = _WinAPI_GetModuleHandle(Null)
    Local $hImage = _GDIPlus_BitmapCreateFromResource($hMod, $sResNameOrID)
    $bReturn = _GDIPlus_ImageSaveToFile($hImage, $sFilePath)
    _GDIPlus_ImageDispose($hImage)
    If @error Then MsgBox(64, @ScriptName, '$bReturn = ' & $bReturn & @CRLF & '@error = ' & @error & @CRLF & '@extended = ' & @extended & @CRLF & @CRLF & $sFilePath)
    ; ...
  • Vielleicht bringt der FileHeader der Bitmap das Ausleseverfahren durcheinander?

    Hab mir das nie angeschaut, weil ich kein persönliches Interesse daran habe. Aber falls dem so sein sollte wäre es z.B. möglich eine base64 (De)Kodierung für sämtliche zu speichernden Daten zu verwenden. Dadurch sollten Konflikte komplett ausgeschlossen sein. Das geht dann aber halt zu lasten der Performance und Speicherplatzeffizienz.