Dateiprobleme unter Vista und 7

[Jan]

In meiner Updateroutine wird im Netz nachgesehen, ob eine der dll oder die exe eine neue Version haben. Wenn ja, dann ist die Vorgehensweise diese hier:

- Die vorhandene dll oder exe umbenennen mit der Endung .alt
- Die neue dll per LoadFromUrl von Phil heruterladen und unter dem Dateinamen speichern.
- Aufforderung, das Programm neu zu starten.

Das funktioniert auch super. Aber nicht unter Vista und 7. Denn da wird zwar die alte Datei umbenannt. Aber die neue nicht gespeichert. Es wird die alte wieder abgelegt. Ich tippe da mal auf Systemwiederherstellung, ist aber nur geraten.

Ich habe Abfragen eingebaut, um zu sehen, ob irgendwo ein FError() auftaucht. Nix. Auch nicht bei FWrite() der neuen Datei. Alles läuft sauber durch.

Hat jemand eine Idee, was da passiert und wie ich das umgehen kann?

Jan

[brandelh]

Hi,

liegen die DLL unter dem c:\Programme Ordner ?
gleiches Verhalten auch als Admin ?

wenn ja, liegt es wohl an der USER Schutzumleitung ... versuche mal die Update Routine AS ADMINISTRATOR ablaufen zu lassen (irgendwo in den Dateieigenschaften).

[Jan]

Hallo Hubert,

nein, seit den massiven Problemen mit C:\Programme unter Windows 7 hab ich das von da weg umgebogen.

Admin weiß ich nicht, muß ich mal den User fragen. Liefer ich nach.

Jan

[brandelh]

Wenn Windos7 wirklich der Meinung ist, dass das nicht erlaubt ist,
kann man eventuell das Verzeichnis komplett von der Wiederherstellung ausnehmen ?

[brandelh]

Hi,

also ich habe mein Installationsprogramm mal getestet und festgestellt, dass es noch mit 1.82 compiliert war ... gleich neu kompiliert und es geht.
Ich gehe allerdings anders vor ...

1. Anwendungsprogramm (nicht Admin) startet aus Menü asyncron mein Update-Programm und beendet sich dann komplett (inkl. der DLL !)
2. Das Update-Programm liegt in einem anderen Verzeichnis und hat alle DLL bei sich.
3. Vor Update die neu ZIP laden, temporär entpacken und bei Fehler beenden
4. Sonst Zielverzeichnis alle DLL und EXE und INDEXE löschen.
5. Neue Dateien ins Zielverzeichnis verschieben
6. Beenden

Anwender startet danach über das Menü die neue Programmversion. NUR das Updateprogramm habe ich per Kontextmenu auf ADMIN ausführen für alle USER gesetzt.
Beim Start erscheint dann auch immer die Abfrage ob das Programm "von Unbekannt" auf die Festplatte zugreifen darf ! JAAAAAA

[AUGE_OHR]

In meiner Updateroutine wird im Netz nachgesehen, ob eine der dll oder die exe eine neue Version haben. Wenn ja, dann ist die Vorgehensweise diese hier:
- Die vorhandene dll oder exe umbenennen mit der Endung .alt

em... äh ... mit "was" ist deine "Updateroutine" compiliert ?
wenn mit Xbase++ ... "welche" DLL werden "geladen" (Dependency Walker) ?

Die *.DLL, die du "updaten" möchtes : werden die von der "Updateroutine" genutzt ?

man kann eine "geladene" DLL nicht "umbenennen", vielmehr wird eine Kopie erstellt.

mach mal ein DIR c:\Users\Name_des_User\AppData\Local\Virtualstore und lass dir anzeigen was da so alles rumliegt...

[Jan]

Moin Jimmy,

alles mit Xbase++ kompiliert. Mit was auch sonst?
Ja, die werden teilweise von der Updateroutine genutzt. Aber nicht alle.
Doch, man kann die offensichtlich umbenennen. Denn erstens gibt FError() mir nichts zurück, und außerdem geht es ja unter XP.

Ich denke, ich werde mal Huberts Idee folgen und die herutergeladenen Daetien in einem Update-Verzeichnis speichern. Und dann vermutlich beim nächsten Programmstart oder sowas rüberkopieren. Einen Versuch ist das mal wert.

Jan

[brandelh]

Hi,

als wir noch lokale EXE meiner Netzwerkprogramme hatten, habe ich immer alle Programme
über eine Batchdatei gestartet. In der EXE habe ich die Versionsnummern mit denen eines
zentralen Verzeichnisses überprüft und wenn dort was neueres lag habe ich ErrorLevel( 10 )
gesetzt und das Programm beendet.

Code: Alles auswählen

MyProgramm.exe
if errorlevel==10 goto update
goto ende
:update
...
:ende

Seit Citrix darf ich das nicht mehr und muss warten bis der Dienstleister die EXE austauscht

Bei meiner Tante nutze ich das Internet Update Programm und das ist zwar auch eine Xbase++ Anwendung, aber eben in einem getrennten Verzeichnis. Daher können beide unterschiedliche Versionen haben und es kann auf alles zugreifen was geschlossen ist

[Jan]

Dumm gelaufen. Leider funtkioniert das mit extra Update-Verzeichnis und per Batch vor dem Programmstart rüberkopieren auch nicht. Der DOS-Prompt erzählt mir zwar, daß die Updatedateien kopiert wurden, aber danach sind doch wieder die alten Dateien da.

Langsam gehen mitr die Ideen aus ...


Jan

[AUGE_OHR]

Dumm gelaufen. Leider funktioniert das mit extra Update-Verzeichnis und per Batch vor dem Programmstart rüberkopieren auch nicht. Der DOS-Prompt erzählt mir zwar, daß die Updatedateien kopiert wurden, aber danach sind doch wieder die alten Dateien da.

Langsam gehen mir die Ideen aus ...

Frage : wird vor/nach dem Update rebootet ?

Ich tippe das auf "Cache" und auch das er die DLL noch "im Speicher" hat.

Code: Alles auswählen

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\AlwaysUnloadDll
auf 1 setzten

Auch Application werden nicht sofort entladen.

Code: Alles auswählen

HKEY_CURRENT_USER\Control Panel\Desktop
WaitToKillAppTimeout auf 1000 und
AutoEndTasks auf 1

und für das ganze lesen/schreiben ist ja SMB zuständig ... unter Vista/Win7 SMB2

Code: Alles auswählen

Deaktivierung von SMB 2.0 unter Windows 7 als Client-Computer

1. Öffnen Sie eine Eingabeaufforderung als Administrator.

2. Führen Sie folgende Befehle aus:
sc config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc config mrxsmb20 start= disabled

3. Starten Sie den Computer neu.

und Retour mit

Code: Alles auswählen

Aktivierung von SMB 2.0 unter Windows 7 als Client-Computer

1. Öffnen Sie eine Eingabeaufforderung als Administrator.

2. Führen Sie folgende Befehle aus:
sc config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc config mrxsmb20 start= auto

3. Starten Sie den Computer neu.

[Jan]

Jimmy,

ist ja sicher gut gemeint. Hilft aber überhaupt garnicht weiter. Ich kann doch vom Anwender nicht erwarten, 2 dutzend Einstellungen in der Registry vorzunehmen, nur damit mein Programm Online-Updates durchführen kann. Das muß doch auch anders gehen, andere Programme bekommen das doch auch hin. Irgendwie.

Jan

[brandelh]

Versuche doch mal per Hand die Update CMD zu starten.
Was passiert dann ?

Wenn es dann funktioniert, dann liegt es daran, dass deine EXE nicht schnell genug geschlossen wird.
Ich verstehe nur nicht warum es bei mir geht und bei dir nicht. Hast du der CMD per contextmenü "Als Administrator" eingestellt, eventuell noch Ausführen unter Administrator ...

Wie sind denn die Pfade ?

[AUGE_OHR]

Ich kann doch vom Anwender nicht erwarten, 2 dutzend Einstellungen in der Registry vorzunehmen,

wieso Anwender, du hast doch eine Update Routine und per REGCLASS kannst du die Einträge in der Registry setzen/kontrollieren.

nur damit mein Programm Online-Updates durchführen kann.

na dann fange doch mal die "temporären" Daten beim M$ Updates ab und siehe mal in die Scripte ...

Die Sicherheitsmassnahmen von Vista / Win7 sollen ja eben gerade "verhindern" das "User" DLL löschen oder überschreiben.
Man muss schon (temporäre) Administrator Rechte dafür haben und DLL müssen ggf. "entladen" werden bevor man sie "löschen" kann.

Das muß doch auch anders gehen, andere Programme bekommen das doch auch hin. Irgendwie.

Nein das selbe Problem haben auch VB oder Access Anwendungen wenn es "User" sind.

Frage : wird dein Xbase++ Application Verzeichniss vom Administor oder User angelegt (Erstbesitzer) ?

[Jan]

Versuche doch mal per Hand die Update CMD zu starten.
Was passiert dann ?

Muß ich heute Abend mal versuchen. Das Problem ist, daß ich die Batch-Datei aus dem Programm heruas erstelle, und beim nächsten Start, nach dem update, wieder lösche.

Wenn es dann funktioniert, dann liegt es daran, dass deine EXE nicht schnell genug geschlossen wird.

Auch das werde ich mal kontrollieren.

Ich verstehe nur nicht warum es bei mir geht und bei dir nicht. Hast du der CMD per contextmenü "Als Administrator" eingestellt, eventuell noch Ausführen unter Administrator ...

Hmm. das könnte sein. Da gab es doch einen Befehl, mit dem man temporär Admin-Rechte bekommt? Muß ich nachher mal raussuchen, und dann kommt der mit in die Batch.

Wie sind denn die Pfade ?

Nicht C:\Programme. Und das Updateverzeichnis ist ein Unterverzeichnis des Programmverzeichnisses.

Jimmy: Nein, das dürfte nicht das Problem sein. Es ist in der Tat so, daß das Programm mit erzwungenen Adminrechten installiert wird. Aber auf meiner virtuellen Vista-Maschine habe ich selber als normaler User auch Admin-Rechte, und auch da klappt das nicht.

Jan

[brandelh]

Das Problem ist, daß ich die Batch-Datei aus dem Programm heruas erstelle, und beim nächsten Start, nach dem update, wieder lösche.

Damit hat die neue CMD aber USER Rechte ...
Ich habe gerade nachgesehen, ich habe hier Vorgängerversionen des Anwendungsordners, somit habe ich die Wiederherstellungspunkte nicht abgeschaltet.

Ich denke du must der CMD Adminrechte erteilen und am Besten noch unter Adminstrator User laufen lassen.
Ein eigenes Update Programm (so wie ich es verwende) ist aber auf jeden Fall flexibler.

[Jan]

Moin Hubert,

ah, OK. Also muß ich zusehen, daß die Batch Adminrechte bekommt. Ich hab gerade nochmal nachgesehen - angeblich geht das über "net user Administrator /active". Ich werde das mal in der Batch vorne reinstellen, oder direkt aus meinem Programm heraus aufrufen. Mal sehen, was da passiert. Allerdings irritiert mich das - so einfach kann ein normaler User Adminrechte bekommen? Ich bin da etwas skeptisch.

Ansonsten habe ich gesehen, daß man auch in der Manifest-Datei Admin-Rechte einfordern kann. Wäre auch mal ein Versuch wert.

Jan