Wo Programmupdate hinspeichern

[freimatz]

Hallo,
ich möchte aus meinem Programm ein Update vom Internet downloaden, lokal speichern und dann starten.
Wo speichere ich das am Besten ab, so dass das am Besten läuft? Mit wo meine ich sowas wie %Temp%, %AppData% oder ähnlichem.
Bei meinem Prototyp speichere ich das momentan in einen Ordner unterhalb meiner Exe. Ein Tester meldet jedoch das Update würde nicht starten. Ich vermute ein Rechteproblem.

[DieDolly]

Für sowas ist meiner Meinung nach das temporäre Verzeichnis die beste Wahl. Updatedateien haben in AppData nichts zu suchen.
Das Programmverzeichnis ist auch eine gute Wahl. Nur dann muss man sicherstellen, dass das Programm zumindest als Administrator gestartet wurde. Die meisten Probleme sind dann schon weg.

[hoika]

Hallo,

Zitat:

in einen Ordner unterhalb meiner Exe

Wo liegt denn die Exe?

[Schokohase]

Für die lokale Installation sollte man sich für einen Ordner unterhalb von %LOCALAPPDATA% (idR. = %USERPROFILE%\AppData\Local) entscheiden. Das kann auch der %TEMP% (idR. = %LOCALAPPDATA%\Temp) Ordner sein, oder man erstellt einfach einen dedizierten Ordner %LOCALAPPDATA%\<company>\<Product>\Updates dafür.

%APPDATA% (idR. = %USERPROFILE%\AppData\Roaming) eignet sich wegen dem Roaming (kommt bei Betrieb in einer Domain zum Tragen) nicht so gut dafür.

[Luckie]

Zitat:

Zitat von hoika (Beitrag 1417758)

Hallo,

Zitat:

in einen Ordner unterhalb meiner Exe

Wo liegt denn die Exe?

Die Antwort ist unerheblich. Man weiß nie, wohin der Benutzer die Anwendung hin installiert. Man muss vom schlimmst möglichen Fall ausgehen. Und der wäre, wenn der Benutzer keine schreibrechte in einem Ordner hat zum Speichern des Updates. Zumindest speichern sollte ohne Adminrechte gehen. Wenn dann das Update angestoßen wird, kann das Update nach Adminrechten fragen.

[haentschman]

Zitat:

man erstellt einfach einen dedizierten Ordner %LOCALAPPDATA%\<company>\<Product>\Updates dafür.

+:thumb:
...nur heißt er bei mir SYSTEM, statt Updates, weil noch andere systemrelevate Sachen drin sind. 8-) Der Name ist ja wurscht, der Platz ist entscheidend. Den User Ordner halte ich nicht gut. Da sollten nur die Daten drin sein, die dieser User für sich benötigt.

[Schokohase]

Zitat:

Zitat von haentschman (Beitrag 1417784)

Zitat:

man erstellt einfach einen dedizierten Ordner %LOCALAPPDATA%\<company>\<Product>\Updates dafür.

+:thumb:
...nur heißt er bei mir SYSTEM, statt Updates, weil noch andere systemrelevate Sachen drin sind. 8-) Der Name ist ja wurscht, der Platz ist entscheidend. Den User Ordner halte ich nicht gut. Da sollten nur die Daten drin sein, die dieser User für sich benötigt.

Also doch nicht %LOCALAPPDATA%\<company>\<Product>\Updates?

Denn da idR folgendes gilt

Code:

%LOCALAPPDATA% => %USERPROFILE%\AppData\Local
%USERPROFILE% => %HOMEDRIVE%\Users\%USERNAME%

befürwortest du die Verwendung dieses Ordners und gleichzeitig lehnst du diesen ab. Das ist etwas verwirrend.

[haentschman]

Moin...:P

Zitat:

befürwortest du die Verwendung dieses Ordners

...ähmmm, sorry. 8-)
Es ist noch früh am Morgen und zu wenig Koffein. Ich meinte %APPDATA% oder umgangssprachlich ProgramData (gemeinsam für alle User).

[Schokohase]

Zitat:

Zitat von haentschman (Beitrag 1417787)

Moin...:P

Zitat:

befürwortest du die Verwendung dieses Ordners

...ähmmm, sorry. 8-)
Es ist noch früh am Morgen und zu wenig Koffein. Ich meinte %APPDATA% oder umgangssprachlich ProgramData (gemeinsam für alle User).

Das sind aber zwei Paar Schuhe.

Bei mir lösen sich diese wie folgt auf:

Code:

%APPDATA% => APPDATA=C:\Users\Schokohase\AppData\Roaming
%ProgramData% => C:\ProgramData

Wenn der Benutzer das Update anstösst, dann sollten die Daten mMn in einen Ordner unterhalb von

Code:

%LOCALAPPDATA% => C:\Users\Schokohase\AppData\Local

wandern und von dort ausgeführt werden. Das wird dann immer funktionieren, selbst wenn sich der Benutzer mit n anderen Benutzern auf einem Terminal-Server tummelt. Der Ordner ist nur für ihn selber und es gibt keine Überschneidungen mit anderen Benutzern.

Die Installation selber kann man dann leicht per Mutex systemweit einzigartig machen. Worst Case können also n Benutzer das Update anstossen, aber nur einer kann es erfolgreich ausführen (wegen dem Mutex).

[haentschman]

Zitat:

Das sind aber zwei Paar Schuhe.

...ich merke schon, die %..% Order sind nicht meine Welt. :oops: Ich meinte explizit ProgramData...ich hole mir jetzt mal Kaffee. :wink:

[freimatz]

Hallo,
Danke für alle Antworten. Ich nehme dann mal einen Unterordner von TPath.GetTempPath

[freimatz]

Das scheint nun zu funktionieren - zumindest bei den meisten. Bei einem Tester gibt es das Problem, dass er die Datei lädt. Danach liegt auch eine mit dem Namen in dem Ordner, jedoch ist das inhaltlich keine exe sondern eine HTML. Darin steht u.a.:

While trying to retrieve the URL: <meine exe> The content is blocked due to the following condition:

Your organization's Internet access policy suggests you should not be downloading this file type. You may proceed with this download at your own discretion. ...
<a class="orange" href="http://passthrough.fw-notify.net/proceed?extension=exe&filename=...

Mein Programm startet dann die "Exe", was dann nicht funktioniert.

Der Tester hatte zwar einige Vorschläge, aber was meint Ihr?

[mensch72]

ne "exe" irgendwo per WEB hinspeichern schägt auf gut gesicherten Sytemen fehl... das ist auch gut so!

Wenn eh die eigene Applikation das "Update" startet, kann man es auch via "PNG" in einem binary ZIP-TAG unterbringen... das klappt sogar auf Apple OSx&IOS Systemen.
Ich nutze wenn irgend möglich nur noch zipped binary MetaDatenTags via JPGs oder PNGs, nen schickes kleines ICON als echte Bilddaten dazu und es flutscht locker überall in den Dokumenten/Bild Ordner... Endungen wie "exe" oder was auch immer sehen StandardOS-Nutzer doch seit langem nicht mehr... aber die Mini-Vorschau für Bilddateien kennen "alle"!

Bilddateien als zipped binary Container zu mißbrauchen ist nicht ganz die feine Art, aber zumindest bei PNGs ist das sogar gemäß strenger Apple Richtlinien 100% erlaubt, weil so im PNG Standard echt vorgesehen und von Apple voll unterstützt!

=> es kommt aus meiner Sicht also nicht wirklich darauf an "wo" man etwas speichert, sondern viel wichtiger ist "wie" man etwas speichert!

[Schokohase]

Wenn du den Response-Header auswerten würdest, dann würdest du unterscheiden können, ob du jetzt das Update bekommst, oder eben so ein HTML.

Bei Update -> speichern und Update ausführen
Bei HTML -> anzeigen

In diesem Fall kann der Benutzer wohl über diesen die EXE herunterladen, muss das Update dann aber manuell durchführen.

[DieDolly]

Zitat:

=> es kommt aus meiner Sicht also nicht wirklich darauf an "wo" man etwas speichert, sondern viel wichtiger ist "wie" man etwas speichert!

Beim Herunterladen der nackten Dateien kann man aber vorher den Hash prüfen und mit der lokalen Datei gegenprüfen. Erspart unnötige Downloads.
Viele Entwickler machen es sich da ganz einfach und lassen einfach nur ein Setup laden.

[freimatz]

Hoi,
Danke für die vielen Rückmeldungen. Insgesammt sehe ich das als recht aufwendig an wenn ich das ordentlich machen möchte. Als kurzfristige "Lösung" mache ich eine kleine Prüfung der Datei und gebe nun ggf. eine Fehlermeldung mit URL aus. Dann mag der Anwender selber schauen wie er die Setup-Datei auf seinen Rechner bekommt. (Ist sowieso eher ein exotisches Problem.)

@mensch72: Das erscheint mir als ein Ausnutzen einer Lücke der Firewall zu sein (genausso wie der Vorschlag des Testers die exe umzubennnen)

@Schokohase: Das wäre wohl die sauberste Lösung. Leider komme ich an den Header nicht ran. Derzeit verwende ich WinInet für das Laden. Ich dachte auch schon daran das auf Indy umzustellen das ich woanders auch schon benutze. Da wäre das einfacher.

@DieDolly: Ein Hash ist mir derzeit zu aufwendig. Würde bei diesem Problem auch nicht helfen.

Nochmals Danke an alle!
freimatz

[mensch72]

..."@mensch72: Das erscheint mir als ein Ausnutzen einer Lücke der Firewall zu sein (genausso wie der Vorschlag des Testers die exe umzubennnen)"...

- ja, einfach exe oder zip umbenennen umbenennen wäre nen typischer Test für Virentests... das müssen die erkennen und automatisch als Gefahr ausweisen.
Wenn so "Contentfilter" schon als LowLevelFirewall und gar auf exterener Hardware laufen, ist da was besseres am Start (Symantec bietet sowas z.B. Standalone auf Ent. Level)

- aber sagen wir die Anwendung Metadaten von Bilddateien(z.B. PNG&JPEG) mit "speziellen" Nutzinformationen zu versehen kommt aus der Apple-Offline-Welt!
Ohne installiertes ITunes funktioniert bei IPhones&IPads nur der Bilddatentransfer von/zu jedem per USB Kabel angeschlossenem "Fremdrechner".
Also mal fix ein Fehlerlog oder einen lokales Backup/Restore einer SQlite-DB ist für Ottonormal Apple Anwender sobald er in freier Wildbahn offline (oder gar Sibieren/Wüste/...) mal was austauschen oder empfangen soll schlicht auf ECHTE Bilddateien begrenzt(also auch da keine nur umbenannten ZIP/... Dateien!).

Das dies funktioniert ist Hersteller und Betriebssystem übergreifend so gewollt und hat nix mit einer Lücke z.B. in der Firewall zu tun:)
Prof. Kamerasysteme verstecken da spezielle Farbraumdaten oder bisherige Filtermatritzen, damit "nur die eigene Spezialsoftware" bei Weiterverarbeitung dies beachten kann.
Oder wegen Datenschutz müssen Backlinks in zu den Bilddaten besonders vor Fremdzugriff geschützt werden... also wenn in einem Bild 5Leute zu sehen sind und deren pers. Daten bekannt und verlinkt sind, dürfen diese Informationenn bei Weitergabe nicht offen für alle weiter verfügbar sein... weil da harte & gute Schutzalgos nun (hoffentlich) normal sind, kann sich kein aktiver Contentfilter daran stören, wenn eine Bilddatei voll nach Standard vorgesehene zusätzliche beliebige Metadaten inetgriert hat.

=> die Methode ist daher sowohl der sehr sicher, hoch kompatibel und vor allem sehr Endanwender freundlich, denn Fotos vom/zum Smartphone via Rechner... das ist aktuell hoch verbreitetes Basiswissen von jund bis alt


Wer für online wie offline verfügbar was vergleichbar einfaches und universelles hat, möge es mir bitte sagen.

[Schokohase]

An den Header kommt man sehr leicht heran, wenn man das richtig angeht. Hier mal ein kleines Beipiel, wie das prinzipiell gehen könnte:

Delphi-Quellcode:

uses
  Winapi.ShellAPI,
  Winapi.Windows,
  System.Classes,
  System.SysUtils,
  System.Net.HttpClient;

procedure DownloadFile( const AUrl: string; const AMimeType: string; const AStream: TStream );
var
  clt:      THttpCLient;
  response: IHTTPResponse;
begin
  clt := THttpCLient.Create( );
  try

    response := clt.Get( AUrl );
    if response.StatusCode = 200
    then
      begin
        if response.MimeType = AMimeType
        then
          begin
            AStream.CopyFrom( response.ContentStream, response.ContentLength );
          end else if response.MimeType.StartsWith( 'text/html', true )
        then
          begin
            ShellExecute( 0, 'open', PChar( AUrl ), nil, nil, SW_SHOW );
          end
        else
          raise Exception.CreateFmt( 'Unexpected Content-Type %s', [response.MimeType] );
      end
    else
      raise Exception.CreateFmt( 'Unexcepted StatusCode %d (%s)', [response.StatusCode, response.StatusText] );

  finally
    clt.Free( );
  end;
end;

procedure Main;
var
  stream: TMemoryStream;
begin
  stream := TMemoryStream.Create;
  try
    DownloadFile( 'https://www.delphipraxis.net/attachments/50203d1541379986-kodezwergs-tinihelper-klasse-inihelper.7z', 'application/x-7z-compressed', stream );
    WriteLn( stream.Size );
    stream.Clear( );
    DownloadFile( 'https://avm.de/fileadmin/user_upload/DE/Labor/Download/fritzbox-7590-labor-63282.zip', 'application/zip', stream );
    WriteLn( stream.Size );
    stream.Clear( );
  finally
    stream.Free;
  end;
end;

[Delphi.Narium]

Kann man für den Header nicht einfach

Delphi-Quellcode:

response := clt.Head(AUrl);

nehmen, damit kommt man den HTTP-üblichen Header, der alle Infos enthält.

Da steht dann drinne, welcher Mimetype geliefert wird, wie groß das Ergebnis sein wird, ob man auf 'ne andere Seite umgeleitet werden soll, welcher Responscode bei 'nem Get zu erwarten ist, ...

Also eigentlich alles, um anschließend gezielt weiterarbeiten zu können, sei es Download der gewünschten Datei oder eben Fehlerbehandlung, wenn die Datei nicht verfügbar ist.

Zitat:

Zitat von https://developer.mozilla.org/de/docs/Web/HTTP/Methods

GET
The GET method requests a representation of the specified resource. Requests using GET should only retrieve data.
HEAD
The HEAD method asks for a response identical to that of a GET request, but without the response body.

https://tools.ietf.org/html/rfc7231#section-4.3.2

[Schokohase]

Zitat:

Zitat von Delphi.Narium (Beitrag 1418347)

Kann man für den Header nicht einfach

Delphi-Quellcode:

response := clt.Head(AUrl);

nehmen, damit kommt man den HTTP-üblichen Header, der alle Infos enthält.

Warum sollte man das nicht können?

[Delphi.Narium]

Wegen

Zitat:

Zitat von freimatz

Leider komme ich an den Header nicht ran.

[freimatz]

Mit Betonung auf "ich" und für den Zeitpunkt von heute morgen.:wink: Hat sich ja nun gründlich geändert. Danke:thumb: