ac'tivAid

Ich habe es selber noch nicht getestet, aber in Beta 24 merkt sich ac'tivAid in einigen Fällen schon das letzte Arbeitsverzeichnis.

Bei der Update-Funktion bestehen leider immer noch Probleme mit der Verzeichnishandhabung (Beta 51):

- Klicken auf "Auf Aktualisierung prüfen", nach Rückfrage und Wechsel in den Administratormodus (Passwortdialog) erscheint ac'tivAid mit dem anderen Profil im Adminmodus, jedoch wird die Aktualisierung nicht durchgeführt. Sie muss nochmals gestartet werden. Das scheint wohl mit dem Wechsel des Profils zusammenzuhängen, oder?

- Beim Verlassen des Administratormodus trägt ac'tivAid in der Verknüpfung im Autostart-Ordner ohne Nachfrage für das Arbeitsverzeichnis den Standardpfad für den Mehrbenutzermodus ein. Das ist lästig, da meine Verknüpfung mit dem gesonderten Pfad (siehe oben) wieder neu angelegt werden muss.

Lade doch bitte mal Beta 55 manuell hier runter und installiere es bei dir drüber. Ich habe da leichte Anpassungen vorgenommen. Ändere nach der Installation und dem ersten Start von ac'tivAid Zeile 57 von ac'tivAid.ahk z. B. in ScriptVersion = 1.1.7 und lade es neu. Probiere danach mal die Update-Funktionen.

Danke! Nach dem Aufruf der Update-Funktion und dem anschließenden Wechsel in den Admin-Modus wird die Aktualisierung (bzw. das Herunterladen der neuen Version) nun automatisch fortgeführt.

Toll fände ich es, wenn nun noch der Admin-Modus nach dem Updatevorgang wieder automatisch verlassen wird, so dass ich mir den Aufruf des entsprechenden Menüpunktes ersparen kann. (Nein, ich bin überhaupt nicht anspruchsvoll... )

Bitte wiederhole die die Schritte noch mal, ich habe Beta55 nochmals ersetzt. Getestet habe ich es aber noch nicht. Wenn du die Kennwörter nicht speicherst, wird's aber nicht automatisch klappen.

Das Update auf Beta 56 hat auf dem einen Rechner ebenso wie vorher (nach Deinen Anweisungen) funktioniert.

Schade, dass man die Kennwörter speichern muss, wovon ja eigentlich im Passwortdialog (implizit) abgeraten wird. Eigentlich wird ac'tivAid nach dem Update wieder in der aktuellen Benutzerumgebung gestartet, wozu wird dann noch ein (abgespeichertes) Passwort benötigt (Frage aus reiner Neugier)?

Noch was: Auf einem anderen Rechner habe ich Probleme mit dem Update (bin wie auf dem erstgenannten Rechner vorgangen). Die Passwörter werden nicht akzeptiert und wenn ich den Passwortdialog per "Abbrechen" beende, wird auch ac'tivAid beendet. Beim Neustart von ac'tivAid erscheint dann wieder der Passwortdialog. Aber das muss ich nochmal genauer untersuchen (wahrscheinlich erst am Wochenende), da dort bis Dato kein Passwort für den Benutzer aktiviert war (erst für das Update eingerichtet) und noch ein Registry-Einstellung eventuell geändert werden muss. Ich melde mich dann nochmal.

Das Problem ist, dass ac'tivAid wie MachMichAdmin die Benutzerrechte des aktuellen Benutzers kurz verändert. Dazu sind Admin-Rechte nötig. Eingeschränkte Nutzer dürfen ihre Rechte nicht ändern. Würde ich ac'tivAid einfach mit anderem Benutzer starten wäre das eben, als würde man sich mit einem anderen Account anmelden und ac'tivAid hat eine ganze andere Umgebung wie Registry und Systemvariablen.

Du musst die Kennwörter nicht speichern, es wird auch nicht empfohlen. Dann musst du aber sie aber immer eintippen.

Wie in der Hilfe beschrieben müssen die Benutzer Passwörter haben, sonst klappt der Wechsel nicht. Ist eine Einschränkung vom RunAs-Befehl.

Danke für die Ausführung. Anhand dieser und meiner Tests mit ac'tivAid komme ich zu dem Schluss, dass beim Updatevorgang bei mir etwas grundsätzlich noch nicht richtig läuft. Da ja der MachMichAdmin-Mechanismus zum tragen kommt, müsste der gesamte Updatevorgang (auch im Administrator-Modus) immer mit dem aktuellen Profil durchlaufen werden. Es ist nun aber so, dass nach dem Passwortdialog ein anderes Profil geladen wird. Und deswegen scheint der Ablauf mitunter durcheinander zu geraten.

Im manuell aufgerufenen Administrator-Modus (Menü activAid | ac'tivAid mit Administrator-Rechten starten) wird tatsächlich das aktuelle Profil geladen (bei mir "D:\ac'tivAid"). Also funktioniert der MachMichAdmin-Effekt hier schonmal.

Beim Update landet ac'tivAid im Admin-Modus jedoch in "C:\Programme\ac'tivAid". Das ist, denke ich, nicht gewollt, oder?

In Bezug auf das zuletzt Geschriebene: Ich bin kein großer Programmierer vor dem Herrn, aber kann es sein, dass in ac'tivAid.ahk (Beta 66) in der Update-Routine sub_NewVersion nach dem Herunterladen des Updates und vor dem Neuladen des Skripts eine Befehlszeile

SetWorkingDir, %WorkingDir%

fehlt (nach Zeile 6386, eventuell besser an anderer Stelle)? Dann müsste das Neuladen ja wieder im bisherigen Arbeitsverzeichnis geschehen. (Klappt hier jedoch nicht, da die Updatefunktion aus dem Internet wieder eine Skriptversion ohne diese Zeile lädt. Deswegen nur eine Vermutung ohne Überprüfung.)

Mensch, das könnte es wirklich sein. Ich habe mal eine neue Version hochgeladen, aber mangels Zeit nicht getestet.

In Beta68 funktioniert es leider immer noch nicht. ac'tivAid lädt nach dem Bestätigen zum Neuladen das Profil aus dem Programmverzeichnis (C:\Programme\ac'tivAid) statt aus dem ursprünglichen Arbeitsverzeichnis. Nach dem Verlassen des Administrator-Modus ist dann wieder die ursprüngliche Konfiguration aktiv.

OT: Eine Antwort auf einen Hinweis, den ich erst zwei Minuten später absende? Wow, Du musst ja wirklich in Zeitnot sein.

Evtl. klappt es jetzt. Falls nicht, probiere mal ac'tivAid.ahk anzupassen und setze ScriptVersion in Zeile 57 mal eine Version tiefer. Schaue, ob dann alles klappt.

Sorry, funktioniert immer noch nicht (auch nicht mit dem Trick der Versionsanpassung). Er landet direkt nach dem Neuladen immer im Programmverzeichnis.

Die neue (?) Abfrage, um den Administrator-Modus direkt wieder zu verlassen, funktioniert leider auch nicht. Wenn ich die Frage bejahe, landet er ebenso mit Administratoren-Rechten im Programmverzeichnis.

Irgendwo fehlt die Angabe des ursprünglichen Arbeitsverzeichnisses bzw. will ac'tivAid diese nicht annehmen, nur wo?

Super, Beta70 funktioniert, auch die Abfrage zum direkten Neuladen ohne Admin-Rechte. Da ist ja noch einiges an Code eingeflossen. Danke für die Arbeit!

Mit Beta 72 auch noch.

Bei Beta72 läuft der Updatevorgang wie bei Beta70, also gut.

Bei einem Versuch ist ein Fehler aufgetreten, da eine Datei (RemoveDrive.exe) nicht ersetzt werden konnte (das Programm lief noch, bedingt durch eine Fehlbedienung), dadurch ist der Update-Ablauf jedoch gegen Ende ziemlich durcheinandergekommen. Soll ich dazu nochmal eine extra Aufgabe anlegen?

Schildere mal genau, was du gemacht hast und was dann passiert ist. Wie hast du festgestellt, dass RemoveDrive.exe nicht ersetzt werden konnte?

Hier der Vorgang, so dass RemoveDrive noch läuft:

1. Erweiterung Eject, unter Gerätenamen zuweisen den Eintrag "H" → "RemoveDrive.exe H: -l" anlegen (das Problem hierbei ist das ".exe" im Programmnamen, ohne ".exe" funktioniert es).
2. Beim Anwenden der Tastenkombination bleibt das halbtransparente Auswurfsymbol auf dem Desktop stehen, da ac'tivAid zusätzlich ".exe" als Parameter an RemoveDrive übergibt und RemoveDrive hängen bleibt. (Hinweis: Das Programm ProcessExplorer von Sysinternals hilft mir hier bei der Analyse.)
3. ac'tivAid neu starten, um das Auswurfsymbol zu beseitigen. RemoveDrive bleibt als Prozess im Hintergrund bestehen.

Da ich zum Zeitpunkt des Updates nicht wusste, dass RemoveDrive noch läuft, kam es dann zu folgendem Ablauf:

1. Nach der Eingabe des Admin-Passwortes und dem Herunterladen der neuen Version erscheint eine Fehlermeldung "Fehler - Einige Dateien konnten nicht erstellt werden. Bitte schließen Sie [...]". Ok betätigen.
2. Es erscheint ein Fenster "Selbstentpackendes WinRAR-Archiv" mit einer Aktionsliste, die den rot hervorgehobenen Eintrag "Kann Library\tools\RemoveDrive.exe nicht erstellen." enthält. Schließen oder Abbruch betätigen (kein Unterschied beim folgenden Ablauf).
3. Eine weitere Fehlermeldung "Aktualisierung fehlgeschlagen. Prüfen Sie Ihre Internetverbindung [...]" erscheint. OK betätigen.
4. Der Hinweis "Achtung: ac'tivAid läuft mit Administratoren-Rechten. [...]" erscheint, wobei die Titelzeile noch die bisherige ac'tivAid-Versionsnummer anzeigt. OK betätigen.
5. Ab hier wird ac'tivAid sehr träge, erzeugt jedoch keine signifikante CPU-Last. Es dauert nach einem Doppelklick auf das Tray-Symbol ca. eine halbe Minute bis das Hauptfenster erscheint, der Ladestatusbalken bleibt länger in der Mitte hängen. Erst nach ca. 3 Minuten ist der Ladevorgang beendet (es sind 18 Erweiterungen aktiv). Das Hauptfenster zeigt immer noch die vorherige Versionsnummer an und es ist noch das ursprüngliche Profil geladen.
6. Menüpunkt ac'tivAid | Administrator-Modus verlassen" auswählen. Es erfolgt eine Passwortabfrage.
7. In der Passwortabfrage das Administratorpasswort eingeben. ac'tivAid wird neu geladen, nun als neue Version.
8. Nach dem Neuladen erscheint der Hinweis "Achtung: ac'tivAid läuft mit Administrator-Rechten. Falls Sie nicht generell [...]". OK betätigen. Es ist immer noch das bisherige Profil geladen (Einzelbenutzer-Modus, Admin).
9. Wieder ac'tivAid | Administrator-Modus verlassen ausführen. Diesmal wird ac'tivAid jedoch mit dem Profil aus dem Verzeichniszweig %APPDATA%\ac'tivAid geladen und ist im Mehrbenutzer-Modus.
10. Dummerweise wird dann auch gleich der Eintrag im Autostart-Ordner entsprechend geändert, was dann manuell wieder geändert werden muss.

[Edit] Punkte in den Listen durch Zahlen ersetzt wegen der besseren Übersichtlichkeit.

Vielleicht noch der Nachtrag: Das Problem mit RemoveDrive sehe ich nicht so eng, zumal Du im entsprechenden Eject-Dialog ja auch auf Gefahren hinweist. Das soll hier eher als Beispiel für die Problematik mit der Update-Funktion dienen.

Stellt sich nun die Frage, ob das Problem nur bei deinen beschriebenen Konflikten auftritt. Du schreibt nach "Aktualisierung fehlgeschlagen ...", dass der Admin-Hinweis mit alter Versionsnummer erscheint. Hast du dazwischen ac'tivAid neu geladen? Da du eine neue Versionsnummer erwartet hast, gehe ich davon aus.

Wenn du Zeit hast, versuche das mal mit der neuen Beta zu reproduzieren. Die sollte mit einem Update-Fehler besser umgehen können. Obwohl – ich habe das Problem in Eject ebenfalls beseitigt (steht nicht im Changelog), ist nun also nicht mehr so leicht zu reproduzieren. Vielleicht startest du RemoveDrive manuell, so dass es hängt.

Nein, ich habe keinen manuellen Neustart vor Punkt 4 durchgeführt und auch sonst nicht.

Dass Dateien im ac'tivAid-Programmverzeichnis für den Zugriff gesperrt sind, wird wohl ziemlich selten auftreten. Außer jemand hat da ziemlich an den Zugriffsrechten rumgedreht. Aber im Großen und Ganzen sind das sicherlich Sonderfälle, die nicht unbedingt berücksichtigt werden müssen. Ich wollte halt nur mal darauf hinweisen, dass sowas passieren kann, weil es mir passiert ist.

Gerade getestet. Das Update hat geklappt. Kann es sein, dass ac'tivAid den RemoveDrive-Prozess einfach abschießt? Oder hat der RAR-Entpacker eine Funktion, laufende Prozesse zu ignorieren?

Nein, dann war RemoveDrive wohl nicht blockiert. Das einzige was ich geändert habe ist, dass ac'tivAid vor dem Entpacken ein Backup anlegt und dieses bei einem Entpackfehler wiederherstellt.

Ich habe in den Eject-Einstellungen für RemoveDrive einfach wirre Parameter angegeben, so dass RemoveDrive nicht beendet wird.

Das Verhalten beim Update bleibt wie oben bis zum Punkt 6 beschrieben gleich (auch die Trägheit), außer, dass die Passwortabfrage aus Punkt 6 nicht mehr erfolgt, sondern ac'tivAid tatsächlich die alte Version wieder im ursprünglichen Zustand lädt.