3. Updater basteln

Updater basteln


  • Shade Of Mine schrieb:

    Und diese Update Services sollen sich natürlich nicht ins Systray legen sondern im Hintergrund laufen - bzw. eben nur ab und zu angestoßen werden...

    Update-Service braucht man mMn. gar keins, das kann das Programm doch übernehmen wenn es normal läuft.
    Jedes mal wenn die Software gestartet wird guckt sie nach ob ein Update fertig runtergeladen wurde. Wenn ja -> anbieten zu installieren. Wenn nein guckt sie ob ihr Updater-Daemon schon läuft. Wenn ja -> fertig. Wenn nein nachgucken ob's Zeit zum nachgucken ist. Wenn ja nachgucken ob es ein neues Update gibt. Wenn ja den Updater-Daemon starten, der das dann runterlädt.

    So braucht man kein Service und die Software wird auch keinen Traffic mehr erzeugen sobald sie nicht mehr gestartet wird.

    0
  • S

    zwutz schrieb:

    Shade Of Mine schrieb:

    David W schrieb:

    Chrome wird in das Benutzerverzeichnis installiert wo er keine Admin rechte braucht. (Warum Chrome "GoogleUpdate.exe" laufen hat ist mir schleierhaft, das könnte Chrome selber übernehmen.)
    Das ist der Grund warum es silent Updates sind, nicht wegen dem Prozess.

    Also unter OS X ist das definitiv nicht so. Und Windows habe ich gerade keins da um es dort zu testen...

    so ist es aber unter Windows.

    Habs extra nachgesehen: http://imageshack.us/photo/my-images/849/bildschirmfoto20120814u.png/
    Ist also definitiv nicht der Fall.

    Mag aber so sein, wenn man als User installiert. Da er dann ja nicht nach Programme installieren kann. Ist aber eine sehr sehr dumme Idee.

    @hustbaer:
    Nope.
    Damit verlangst du jedesmal vom User elevated privileges. Die er dir uU nicht geben kann. Der Service hat den Vorteil dass er mit den notwendigen Rechten läuft und nicht extra danach fragen muss. Ein User muss ja nicht unbedingt Admin Rechte haben...

    0

  • Shade Of Mine schrieb:

    @hustbaer:
    Nope.
    Damit verlangst du jedesmal vom User elevated privileges. Die er dir uU nicht geben kann. Der Service hat den Vorteil dass er mit den notwendigen Rechten läuft und nicht extra danach fragen muss. Ein User muss ja nicht unbedingt Admin Rechte haben...

    Willst du das Update vom Service installieren lassen? Hm...
    Weiss nicht ob ich das so gut finde.

    Wo ist das Problem wenn im Falle eines Updates ein UAC Fenster aufpoppt? (Zum Checken/Runterladen/... braucht er ja keine Elevation, bloss zum Installieren)

    0
  • P

    zwutz schrieb:

    Shade Of Mine schrieb:

    David W schrieb:

    Chrome wird in das Benutzerverzeichnis installiert wo er keine Admin rechte braucht. (Warum Chrome "GoogleUpdate.exe" laufen hat ist mir schleierhaft, das könnte Chrome selber übernehmen.)
    Das ist der Grund warum es silent Updates sind, nicht wegen dem Prozess.

    Also unter OS X ist das definitiv nicht so. Und Windows habe ich gerade keins da um es dort zu testen...

    so ist es aber unter Windows.

    AFAIK nur wenn man Chrome direkt mit einem Klick auf "Google chrome jetzt installieren" auf der Google Homepage installiert. (So war es auf jeden Fall bei mir)

    0
  • S

    hustbaer schrieb:

    Willst du das Update vom Service installieren lassen? Hm...
    Weiss nicht ob ich das so gut finde.

    Chrome macht es zB so.
    Systemupdates funktionieren auch auf diese Weise.

    Wo ist das Problem wenn im Falle eines Updates ein UAC Fenster aufpoppt? (Zum Checken/Runterladen/... braucht er ja keine Elevation, bloss zum Installieren)

    Dass der User diese Rechte uU eben nicht hat.

    Es ist eine unsitte immer und überall Adminrechte einzufordern. Das hebelt das ganze System aus. Mittlerweile klicken die User sowieso immer nur weiter weiter weiter wenn ein UAC Dialog kommt. Die Sicherheit ist durch solche Software wie zB Firefox, Java, etc. einfach nicht mehr gegeben und das finde ich bedenklich.

    Aber gut, wenn man unbedingt keine silent updates haben will (warum auch immer) dann muss man mit einem extra Updater arbeiten. Die Software muss dann warnen dass es Updates gibt wenn der User bestätigt popt das UAC auf - sucken tut das ganze natürlich wenn der User keine Adminrechte hat - dann fühlt er sich von der Software verarscht, wie es zB Logitech sehr gut vormacht.

    Generell sollte man aber nicht einfach so nach Admin Rechten Fragen - also in so einem Fall lieber auf händische Updates vertrauen. Denn nichts ist doofer als dem User funktionalität anzubieten (neues Updates, neue Features, etc.) die er dann nicht bekommen kann.

    0
  • E

    Ja, alles so eine Sache. Also meine manifest-Datei funktioniert mittlerweile. Hat jedoch irgendwie einen Neustart gebraucht.

    Chrome (Win7x64) ist bei mir hier installiert:
    C:\Users\:)\AppData\Local\Google\Chrome\Application\chrome.exe

    Und hätte es mich explizit gefragt, wo ich es hinhaben möchte, hätte ich diesen Ort mit Sicherheit nicht angegeben, ich installiere nie etwas dorthin.

    Shade of Mine:
    Ja, also wenn ich nicht über den Service arbeiten sollte (einfach, weil der auch nochmal mehr Aufwand ist und ich evtl. in einem späteren Update einen besseren Updater anbiete), würde ich halt stets mit UAC den Updater aufrufen. Wenn Nutzer keine Rechte kriegen kann, sollte der Updater ja ausgeführt werden ohne Rechte zu haben, richtig? Und für den Fall zeigt der bei mir jetzt die URL an, wo man sich händisch das Update besorgen kann. Ist zwar immer noch umständlich, aber der User fühlt sich dann zumindest nicht ganz so verarscht, er kann es ja einrichten (wobei er zum Runterladen und installieren auch wieder Adminrechte braucht... d.h. im Grunde genommen, kann er einfach den Updater mit Adminrechten starten).

    0
  • C

    Shade Of Mine schrieb:

    ...

    Wo ist das Problem wenn im Falle eines Updates ein UAC Fenster aufpoppt? (Zum Checken/Runterladen/... braucht er ja keine Elevation, bloss zum Installieren)

    Dass der User diese Rechte uU eben nicht hat.

    Es ist eine unsitte immer und überall Adminrechte einzufordern. Das hebelt das ganze System aus. Mittlerweile klicken die User sowieso immer nur weiter weiter weiter wenn ein UAC Dialog kommt...

    Und es nervt natürlich auch einfach. Gegen gewisse Updater hab ich bereits eine solche Antipathie entwickelt das ich reflexartig auf "Nein" klicke damit ich kurzfristig meine Ruhe hab. Nur in sehr entspannten Augenblicken installier ich mal irgendwas, das mehr als einen Mausklick Aufwand erfordert.

    0
  • E

    Bei mir sind's dann zwei 😞

    - Wollen Sie Update installieren?

    - CUA-Klick auf ja (aber den Klick hat man ja selbst mit mehr Sicherheitsbedürfnis gewählt) [wobei ich es - siehe QT-Thread - nicht hinbekomme die exe mit CUA so zu starten, dass der Benutzer auch gefragt wird! system geht auch nicht :(]

    0
  • Administrator

    @Shade Of Mine,
    Der User hat keine Rechte nach "Programme" zu schreiben, aber er soll die Möglichkeit bekommen, Updates zu installieren? Ist das nicht irgendwie widersprüchlich? Sogar fast schon eine Sicherheitslücke?

    Wenn jemand keine Schreibrechte in "Programme" hat, dann soll er auch nicht in der Lage sein, irgendwelche Updates zu installieren. Dann benötigt es jemand, welcher diese Recht auch besitzt und nicht irgendwelche Lösungen, welche diese Sicherheitsmassnahmen umgehen.

    Ich würde daher im Fall eines User ohne Rechte beim ersten Mal nach dem Aufstarten der Applikation einen klaren Hinweis geben, dass ein Update vorhanden ist, aber dazu jemand mit entsprechenden Rechten benötigt wird. Falls der User das Update nicht durchführt, soll fortan irgendwo ein dezenter Hinweis in der Applikation platziert werden.

    Grüssli

    0
  • E

    Hi,

    nochmal eine Frage: Mein Updater funktioniert soweit prima (ein Klick für Ok, einer für CUA). Aber wenn er im Updater eine DLL ersetzen möchte, die das (bereits beendete!) Hauptprogramm nutzt, kommt es manchmal vor, dass er die nicht überschreiben kann, sprich: die Datei ist noch geöffnet. Wieso, wenn doch die exe schon beendet wurde? Laufen die Aufräumarbeiten von exe und dll parallel und nicht voneinander abhängig?

    Wie kann ich das Problem lösen/umgehen?

    0

  • Einfachste Variante: Retry-Schleife 🙂

    0
  • S

    Alternativ geht auch oft ein rename der DLL und diese dann spaeter mal loeschen.

    0
  • E

    Retry-Schleife, hm... das hatte ich im Kopf, aber war unsicher, ob es nicht zu wenig elegant wäre. Aber gut, werde es wohl so umsetzen. 🙂

    Zudem will ich verstehen, wieso die DLL noch geöffnet ist, obwohl die übergeordnete EXE ja schon beendet wurde.

    Aber kann ich eine noch geöffnete DLL umbenennen? Wie löse ich damit das Problem?

    0

  • Eisflamme schrieb:

    Retry-Schleife, hm... das hatte ich im Kopf, aber war unsicher, ob es nicht zu wenig elegant wäre. Aber gut, werde es wohl so umsetzen. 🙂

    Naja, gibt sicher elegantere Möglichkeiten, aber die sind dann vermutlich auch komplizierter 🙂

    Aber kann ich eine noch geöffnete DLL umbenennen?

    Kommt drauf an wie die geöffnet ist.
    Eine .exe die gerade ausgeführt wird kann man normalerweise umbenennen. Eine geladene DLL dann vermutlich auch.
    Wenn das File mit CreateFile geöffnet wurde geht es allerdings nicht.

    Wie löse ich damit das Problem?

    * Alle alten .exen/.dlls umbenennen (irgend ein generierter Filename, halt irgendwas was es in dem Verzeichnis nicht schon gibt).
    * Alle umbenannten Files löschen
    * Wenn ein File dabei nicht gelöscht werden konnte => mit MoveFileEx(name, 0, MOVEFILE_DELAY_UNTIL_REBOOT) zum Löschen beim nächsten Start markieren
    * Neue Files mit den "normalen" Namen schreiben

    0
  • E

    Okay, danke,. 🙂

    Aber wieso ist die DLL überhaupt noch "geöffnet", weiß das jemand? Wenn die Retry-Schleife sicher ist (scheiß auf die Eleganz *hust* [<- hat nichts mit Deinem Nick zu tun]), nehm ich die (kann ja ein kleines wait einbauen, damit ich nicht währenddessen das System bremse). Aber wenn es andere Gründe gibt außer dass da gerade noch was aufgeräumt wird oder so, dann wäre das ja eben keine sichere Lösung. Aber da das meine selbsterstellte DLL ist, wüsste ich nicht, wer die sonst nutzen könnte. 😞

    0

  • Vielleicht gibt's irgendwelche Effekte durch die die DLL wirklich erst kurz nach Beendigung des Prozesses "frei" wird, keine Ahnung.

    Aber...

    Wie beendest du denn den Prozess? Kooperativ? Wartest du darauf dass er beendet wurde (mit WaitForSingleObject auf das Process Handle)?
    Falls du nicht wartest, dann probier mal das einzubauen, und ob du dann das Access Denied/Sharing-Violation immer noch bekommst.
    (Egal ob du den Prozess "kooperativ" beendest oder mit TerminateProcess draufknallst)

    Ich würde es in der Reihenfolge versuchen:
    * Prozess-Handle besorgen
    * Prozess killen bzw. signalisieren dass er sich beenden soll
    * WaitForSingleObject(processHandle, INFINITE)
    * CloseHandle(processHandle)
    * Anfangen Files zu löschen

    Davon abgesehen wären die üblichen Verdächtigen was "gelockte Files" angeht...
    * Explorer.exe (z.B. um das Icon auszulesen oder sonstige Informationen zu ermitteln)
    * Virenscanner
    * Indexingdienst

    Da alle diese Zugriffe recht kurz sind, würde ich sagen dass du mit einer Retry-Schleife gute Chancen hast.

    Kurzes Delay zwischen den Versuchen hast du ja selbst schon erwähnt. Und ein Timeout sollte her. Also dass der Updater nach ner bestimmten Zeit ne Message-Box anzeigt (Failed to update lalablabla -- "Retry" - "Give up").

    0

  • hustbaer schrieb:

    Vielleicht gibt's irgendwelche Effekte durch die die DLL wirklich erst kurz nach Beendigung des Prozesses "frei" wird, keine Ahnung.

    Window's DLL-Cache nach dem Motto "könnt' man ja noch brauchen" 😉 Offenbar gibt es aber keine Möglichkeit eine bestimmte DLL aus dem Cache zu entladen...

    0

  • Wieso sollte der DLL Cache da ein Problem machen?
    Soweit ich weiss werden da Links verwendet (vermutlich Hardlinks, Symlinks auf Files gab's ja unter XP noch gar nicht soweit ich weiss), und dann immer nur der Link im DLL Cache Verzeichnis "aufgemacht", nie das wo anders liegende "Original". Man sollte das "Original" also problemlos löschen können.

    Probleme dürfte es mMn. eigentlich nur geben wenn man das File mit CreateFile aufmacht, z.B. weil man es direkt überschreiben will (=ohne dabei ein neues File zu erzeugen).

    Oder hast du diesbezüglich irgendwelche Infos die etwas anderes vermuten lassen?

    0

  • /Den/ DLL-Cache auf der Platte meinte ich nicht. IIRC behält windows eine DLL noch eine gewisse Zeit im Speicher nachdem alle reference counts 0 sind. Link dazu hab' ich aber auf die Schnelle nicht parat.

    // edit: Vllt. hilft http://msdn.microsoft.com/en-us/library/ms682604(v=vs.85).aspx

    0
  • E

    Also die DLL wird von der EXE einfach nur dynamisch gelinkt mit Hilfe einer LIB. Ich nutze da keine WinAPI-Funktionen. Die einzige WinAPI-Funktion, der zum Tragen kommt, ist ShellExecute, der ruft meinen Updater auf. Daraufhin beende ich die Applikation. Der Updater benötigt dann zumindest eine Sekunde oder so, bis er loslegt bzw. auch 1-3 Sekunden, um das Updater runterzuladen. Und die Applikation ist inzwischen beendet.

    Das Schreiben der Dateien geschieht wegen so einer Unzip-API über Befehle wie _wmakepath und Konsorten...

    0
Anmelden zum Antworten