Appdata, Roaming, etc.

[freimatz]

Hallo,
ich hoffe hier ist das Thema richtig. Ich möchte die Ablage von Dateien meines Programmes mal "richtig" machen. Also wo kommen die Daten hin. Ich habe https://bitreporter.de/windows/wofue...ocal-locallow/ gelesen, so ganz klar ist es mir nicht.

1. Ich habe ein Setup, das kopiert die exe und andere Dateien in den Installationsordner. Das ist soweit klar.

2. a) Dazu gibt es noch weiter Daten, die bei Bedarf dazu installiert werden. Der Anwender startet dazu das Programm, geht auf "Einbindung" und holt sich weitere Inhalte und/oder Funktionen von Diskette, CD-ROM, Datei oder Internet. Bislang lege ich die unter dem Programmordner ab. Das mag Windows jedoch oft mal nicht. Der Umfang ist meist so um die 20MByte, es gibt auch Dinge die auch mal 500 oder 1500MByte haben.
b) Es gibt ein integriertes Hilfesystem. Jje nach eingebunden Dingen wird dies inhaltlich angepasst. Die Dateien dazu liegen auch da.
Ich meine diese Dateien müssten eigentlich in AppData liegen aber wo genau? Roaming oder Local?

3. Es gibt Einstellungen. Die meisten sind in einer INI-Datei. Die liegt je nach Installation auch direkt beim Programm oder in AppData. Im letzteren Fall ist das in %appdata%\<Unternehmsname>\<Produkname>\<Installat ion>. Man mehrere Instanzen meines Programmes installieren. Für jede gibt es da einen Unterordner <Installation>.
Bei den Einstellungen gibt es solche die spezifisch für eine Maschine sind, z.B. welche Dinge eingebunden sind. Dann gibt es Einstellungen vom Benutzer wie z.B. eine Farbe.
Allerdings gibt es die Einstellungen auch in <User>\Dokumente\<Produktname>. Wann welches benutzt wird bin ich mir selber auch nicht mehr klar. Allerdings dürfte auch nur eine Variante richtig sein.

Gibt es irgendwo Empfehlungen zu diesem Thema?

[Bernhard Geyer]

Zitat:

Zitat von freimatz (Beitrag 1461266)

Gibt es irgendwo Empfehlungen zu diesem Thema?

Ja, In der MSDN ...

Es gibt %AppData% (local/roaming). Da sollt das hin was Anwenderspezifisch ist (persönlich Einstellungen, persönliche Daten, ...)
Dann gibt es ProgramData. Dort sollte das hin was für die Anwendung am Lokalen Rechner für alle Nutzer relevant sind und sich ändern können
Programme gehört nur die Anwendungsdateien + "festen" Zusatzdateien hin.

[freimatz]

Danke. ProgramData hatte ich nicht mehr auf dem Schirm. Da hören wohl die Dateien von 2. hin. (und teilweise von 3.)
Hast du noch eine uRL für MSDN. Einiges gegoogelt aber nichts direkt davon gefunden. (Interessant fand ich noch das.)

[Dalai]

Eigentlich ist die Geschichte recht einfach: Alles, was der Nutzer nicht schreiben muss, gehört ins Programmverzeichnis. Sämtliche Einstellungsdateien entweder nutzerspezifisch (%AppData%) oder gemeinsam (%Public% oder %AllUsersProfile% (=%ProgramData%)) ablegen. Im %ProgramData% haben auch Nutzer Schreibrechte. Generell gilt: Je weniger Schreibrechte ein Nutzer an den Dateien hat, desto weniger kann kaputtgemacht werden.

Schwierig wird es dann, wenn der Nutzer Änderungen am Programmumfang vornehmen können soll. Eigentlich sollte sowas dem Admin vorbehalten sein, aber mit einem Neustart als Admin (Verb runas) lässt sich auch das lösen. Für Updates gibt's ja zahlreiche Lösungen, auch wenn nur wenige davon wirklich technisch zufriedenstellend sind.

Der Unterschied %AppData% und %LocalAppData% ist nur für Roaming Profiles in Domänen relevant. Wenn deine Software nicht in derartigen Umgebungen zum Einsatz kommt, brauchst du dir darüber keine Gedanken zu machen (und kannst einfach %AppData% benutzen).

Grüße
Dalai

[freimatz]

Zu 99% sind es Einzelplätze, zumeist privat. Da gibt es keinen Admin. Da passt Dein letzter Satz gut dazu. LocalAppData kann ich mir dann sparen. Danke.
Ob und dass ein Benutzer Schreibrechte hat ist mir relativ egal. Im Supoprtall könnte das nicht schlecht sein.

Den ersten Satz finde ich jedoch nicht "ganz einfach". Was meinst Du mit "Das der Nutzer nicht schreiben muss". Der Anwender schreibt doch selber nie etwas, sondern das Programm. Meinst Du damit sowas wie "Datei|Speichern unter". Wo käme eine Adressdatenbank hin? Wo eine Textdatei, die der Anwender mit dem Programm editieren kann?
Könnte man allgemein sagen, dass alles was man sichern sollte käme in AppData und alle Dateien die das Programm wieder herstellten könnte (wie z.B. Indexdateien) kämen in ProgramData?

[Dalai]

Zitat:

Zitat von freimatz (Beitrag 1461274)

Ob und dass ein Benutzer Schreibrechte hat ist mir relativ egal.

Nicht doch. Genau diese Ansicht sorgt immer wieder dafür, dass Programme im Nutzerprofil landen, wo sie absolut nichts zu suchen haben. Oder ähnlich schlimm, dass Vollzugriff für "Jeder" vom Setup gesetzt wird. So nach dem Motto: "Dann geht's in jedem Fall". Die meisten Admins würden solchen Software-Herstellern am liebsten den Hals rumdrehen, und die Security-Spezialisten übrigens ebenfalls, DLL Sideloading bzw. DLL Hijacking sei da nur als Beispiel genannt.

Zitat:

Den ersten Satz finde ich jedoch nicht "ganz einfach". Was meinst Du mit "Das der Nutzer nicht schreiben muss". Der Anwender schreibt doch selber nie etwas, sondern das Programm.

Ob ein Programm diese Daten schreibt oder der Nutzer an sich, spielt doch keine Rolle. Jedes Programm läuft mit bestimmten Rechten, standardmäßig sind das die des Nutzers. Wenn ein Programm für bestimmte Dinge mehr Rechte braucht, sollte es diese beim Nutzer bzw. beim OS (z.B. per UAC) anfordern.

Zitat:

Wo käme eine Adressdatenbank hin? Wo eine Textdatei, die der Anwender mit dem Programm editieren kann?

Bei der DB kommt es darauf an, ob diese von mehreren Benutzern ver-/bearbeitet werden soll. Wenn ja, dann irgendwo im %Public%, wenn nicht, dann im %AppData% oder vom Benutzer entscheiden lassen.

Zitat:

Könnte man allgemein sagen, dass alles was man sichern sollte käme in AppData und alle Dateien die das Programm wieder herstellten könnte (wie z.B. Indexdateien) kämen in ProgramData?

Muss der Index vom Nutzer (immer wieder) geschrieben werden können? Wenn nicht, dann gehört sowas eher ins Programmverzeichnis.

Ach, noch eine Sache: Verzeichnisse wie %Public%\Documents und %UserProfile%\Documents sind für den Nutzer da, nicht für Daten, die von Programmen abgelegt werden (dafür gibt's %AppData% und %ProgramData%). Mich nervt es immer wieder, wenn ich zwischen den von mir angelegten Verzeichnissen welche sehe, die durch irgendeine Software angelegt wurden, also ohne dass ich das bewusst getan hätte. Mir ist klar, warum Software-Hersteller meinen, das sei eine gute Idee (einfache Auffindbarkeit für den Nutzer, Backup-Möglichkeiten), aber es ist keine wirklich gute Idee.

Grüße
Dalai

[freimatz]

Hallo zusammen,
Danke für alle Antworten. In den letzten Tagen habe ich mich mehr Gedanken gemacht welche Daten es überhaupt gibt in meinem Programm. Über zehn verschiedene Arten habe ich bislang identifiziert.

Schwierig finde ich herauszufinden was "für alle Nutzer relevant" ist und was für den jeweiligen Nutzer spezifisch ist. Ich kenne keinen Anwender meines Programmes, der sich ein PC mit jemand anderen teilt. :) (Ausgenommen ich selber und meine Frau. Auf dem LapTop habe ich das Programm installiert, sie will jedoch keine eigenen Einstellungen.)

Eine neue Frage ist mir aufgetaucht. In etlichen Setups gab es früher die Option "Für alle Benutzer" oder so ähnlich. Was hat das damit auf sich? Wird dann statt %AppData% dann alles in %AllUsersProfile% (oder %ProgramData%) gespeichert? In letzter Zeit habe ich diese nicht mehr gesehen. Ist die nicht mehr wichtig?

@Bernhard: Habe leider in der MSDN noch keine offzielle Doku gefunden geschweige denn eine Empfehlung gefunden. Das Beste war noch eine Doku zu .NET

@Dalai: bin etwas verwirrt. Du schlägst "%Public%" vor (aber nicht %Public%\Documents). Ich komme da bei mir bei in "C:\Users\Public" raus. In %Public% selber ist bei mir fast nichts drin. Lediglich "CyberLink" hat da was reingeschrieben. In %AppData% dagegen habe ich 74 Ordner.

Und wegen %UserProfile%\Documents - hm, ich bin da auch so einer, muss ich noch prüfen. :oops: Ich versuche das dann auch gleich besser zu machen.

[Redeemer]

Zitat:

Zitat von freimatz (Beitrag 1462256)

Hallo zusammen,
Danke für alle Antworten. In den letzten Tagen habe ich mich mehr Gedanken gemacht welche Daten es überhaupt gibt in meinem Programm. Über zehn verschiedene Arten habe ich bislang identifiziert.

Schwierig finde ich herauszufinden was "für alle Nutzer relevant" ist und was für den jeweiligen Nutzer spezifisch ist. Ich kenne keinen Anwender meines Programmes, der sich ein PC mit jemand anderen teilt. :) (Ausgenommen ich selber und meine Frau. Auf dem LapTop habe ich das Programm installiert, sie will jedoch keine eigenen Einstellungen.)

In aller Regel haben Programme keine "für alle Nutzer relevanten" Einstellungen. Mit persönlichen Vorlieben hat das nichts zu tun eher mit administrativen Notwendigkeiten, z.B. allen Benutzern ein Plugin oder ein Sprachpaket installieren können.

Schau dir doch einfach Windows an. Welche Einstellungen können Normalos ändern, was dann alle anderen betrifft? Persönlich fallen mir nur einige Punkte der Eigenschaften von Anzeige ein sowie die Einrichtung von Netzwerkdruckern.

Zitat:

Zitat von freimatz (Beitrag 1462256)

In etlichen Setups gab es früher die Option "Für alle Benutzer" oder so ähnlich.

Da geht es um Verknüpfungen. Sollen die im Startmenü/Desktop von %USERNAME% oder von Öffentlich installiert werden?

[Dalai]

Zitat:

Zitat von freimatz (Beitrag 1462256)

In %Public% selber ist bei mir fast nichts drin. Lediglich "CyberLink" hat da was reingeschrieben.

Naja, jedes Windows hat dort mindestens Documents, Downloads, Pictures, Videos usw.

Zitat:

In %AppData% dagegen habe ich 74 Ordner.

Klar, ist ja nutzerspezifisch. Schau mal unter dem nutzerunabhängigen %ProgramData%, dort dürfte weit weniger liegen.

Zitat:

Und wegen %UserProfile%\Documents - hm, ich bin da auch so einer, muss ich noch prüfen. :oops: Ich versuche das dann auch gleich besser zu machen.

Nicht, dass ich falsch verstanden werde: Für Dateien, die per Speichern-Dialog abgelegt werden sollen, bietet sich %UserProfile%\Documents (als Vorschlag) durchaus an, aber nicht für Dateien, mit denen der Nutzer nichts direkt machen soll. Denn man sollte berücksichtigen, dass sich %UserProfile%\Documents mit Bordmitteln verschieben lässt (Registerkarte "Pfad" in den Eigenschaften), und normalerweise macht der Nutzer das, um die eigenen Daten auf andere Partitionen/Platten zu packen (nicht die Anwendungsdaten von Programmen).

Grüße
Dalai

[freimatz]

Dalai, sorry das verstehe ich immer noch nicht richtig oder es leuchtet mir nicht ein.
Ja, bei mir hat es in %Public% auch Documents, Downloads, Pictures, Videos und so. Aber die Daten meines Programmes passen in keine dieser Kategorien.
In %ProgramData% habe ich 70 Ordner, von Adobe bis XamarinAndroidPlayer. Wenn ich mich dazu gesellen soll verstehe ich das. Aber wieso soll ich etwas in %Public% speichern (so habe ich dich zumindest verstanden) wenn es doch auch sonst fast keiner tut.
Warum sollte z.b. eine DB, die von mehreren Benutzern bearbeitet wird, in %Public% und nicht in %ProgramData%.
(Wegen den %UserProfile%\Documents, ich meine das ist bei mir schon so, dass es nur ein Vorschlag für die eigenen Dateien des Anwender sind.)

[Redeemer]

ProgramData ist das %Appdata% von Öffentlich, sprich für Sachen, die in keine der Kategorien in Eigene Dokumente passen.

Und wie ich schon schrieb, die allermeisten Programme haben keine für alle Nutzer relevanten Dinge, die sie da reinschreiben können.

[freimatz]

Danke ist mir inzwischen klar. Bei meinem Programm dürfte es schon Daten geben die für alle Nutzer relvant sind. Du schriebst von Plugins. So was gibt es auch bei mir. Wenn einer ein neues Plugin einbindet oder ein vorhandenes updated, soll es für alle User gelten (so zu 99% der Konsens.) Das käme dann m.E. in %ProgramData%.

Unklar ist mir nach wie vor die Bedeutung von %Public% (und wo es eine offizielle Doku gibt).
Ich vermute, dass in meinem Fall ich mit %AppData% und %ProgramData% auskomme und %Public% nicht benötige.

[Dalai]

Zitat:

Zitat von freimatz (Beitrag 1462305)

Ja, bei mir hat es in %Public% auch Documents, Downloads, Pictures, Videos und so. Aber die Daten meines Programmes passen in keine dieser Kategorien.

Das ist ja in Ordnung. Dann speichere die Daten nicht dort, hab ich ja auch nicht gesagt, dass du das tun solltest ;). Eher im Gegenteil.

Zitat:

Wenn ich mich dazu gesellen soll verstehe ich das. Aber wieso soll ich etwas in %Public% speichern (so habe ich dich zumindest verstanden) wenn es doch auch sonst fast keiner tut.

Da hast du mich missverstanden, oder ich mich unklar ausgedrückt. Primär bezog ich mich auf die Unterverzeichnisse Documents, Downloads usw., die eben vom Nutzer befüllt werden sollen und nicht von Programmen, denn für letztere gibt es bereits ausreichend Ablageorte (wie eben %ProgramData% und %AppData%).

Grüße
Dalai

[freimatz]

Ah, ok, Danke. :)

[t2000]

Hier mal die Pfade, die wir benutzen:

Delphi-Quellcode:

var
  CompanyDataPath    : string;   // Pfad für Programmdateien FEST auf company z.B. C:\ProgramData\CompanyName\
  ProgramDataPath    : string;   // Pfad für Programmdateien z.B. C:\ProgramData\CompanyName\ProgramName\
  AppDataRoamingPath : string;   // Pfad für Programmdateien-Benutzer (Netzwerk) z.B. C:\Users\Benutzer\AppData\Roaming\CompanyName\ProgramName\
  AppDataLocalPath   : string;   // Pfad für Programmdateien-Benutzer (lokaler PC) z.B. C:\Users\Benutzer\AppData\Local\CompanyName\ProgramName\
  DocumentsPath      : string;   // Pfad für Benutzerdateien z.B. C:\Users\Benutzer\Documents\CompanyName\ProgramName\
  TempPath           : string;   // Pfad für Temp-Ordner z.B. C:\Users\Benutzer\AppData\Local\Temp\

const
  // https://docs.microsoft.com/de-de/windows/win32/shell/knownfolderid
  FOLDERID_ProgramData    : TGUID = '{62AB5D82-FDC1-4DC3-A9DD-070D1D495D97}';
  FOLDERID_RoamingAppData : TGUID = '{3EB685DB-65F9-4CF6-A03A-E3EF65729F3D}';
  FOLDERID_LocalAppData   : TGUID = '{F1B32785-6FBA-4FCF-9D55-7B8E7F157091}';
  FOLDERID_Documents      : TGUID = '{FDD39AD0-238F-46AF-ADB4-6C85480369C7}';

und dazu die Initialisierung

Delphi-Quellcode:

function GetFolderPath( folderId: TGUID): string;
var
  path: LPWSTR;
begin
  if SHGetKnownFolderPath( folderId, KF_FLAG_DEFAULT,  0, path) = S_OK then
  begin
    result := path;
    if copy(result, length(result), 1) <> '\' then
      result := result + '\';
  end else
    result := '';
end;

procedure InitPaths( app: string);
begin
  CompanyDataPath    := GetFolderPath( FOLDERID_ProgramData)    + company + '\';
  ProgramDataPath    := GetFolderPath( FOLDERID_ProgramData)    + company + '\' + app + '\';
  AppDataRoamingPath := GetFolderPath( FOLDERID_RoamingAppData) + company + '\' + app + '\';
  AppDataLocalPath   := GetFolderPath( FOLDERID_LocalAppData)   + company + '\' + app + '\';
  DocumentsPath      := GetFolderPath( FOLDERID_Documents)      + company + '\' + app + '\';
  TempPath           := TPath.GetTempPath;
end;

und noch ein paar Hilfsroutinen

Delphi-Quellcode:

function IsDirectoryWriteable(const Directory: string): Boolean;
var
  FileName: String;
  H: THandle;
begin
  FileName := IncludeTrailingPathDelimiter(Directory) + '_check_write.tmp';
  H := CreateFile(PChar(FileName), GENERIC_READ or GENERIC_WRITE, 0, nil, CREATE_NEW, FILE_ATTRIBUTE_TEMPORARY or FILE_FLAG_DELETE_ON_CLOSE, 0);
  Result := H <> INVALID_HANDLE_VALUE;
  if Result then
    CloseHandle(H);
end;

function IsFileReadOnly(const Filename: string): boolean;
begin
  if FileExists(Filename) then begin
    result := ((GetFileAttributes( PChar(FileName)) and FILE_ATTRIBUTE_READONLY) = FILE_ATTRIBUTE_READONLY);
    if not result then
      result := not IsDirectoryWriteable( ExtractFilePath( Filename));
  end else begin
    result := false; // damit keine Compilerwarung kommt
    Exception.Create('File: '+Filename+' does not exists.');
  end;
end;

[freimatz]

Hallo,
Danke. Eigentlich suchte (und fand) ich ja Antworten auf grundlegendere Dinge.

Wie man die Pfade abfragt, da habe ich schon etwas und zwar verwende ich eine Methode, die ich vermutlich mal irgendwo kopiert habe. Diese verwendet u.a. SHGetSpecialFolderLocation und SHGetPathFromIDList.
Du verwendest SHGetKnownFolderPath.
Und heute bin ich noch zufällig auf TPath.GetPublicPath in unit System.IOUtils gestossen. Das verwendet SetLastError und SHGetFolderPath.
Nun frage ich mich was die beste Methode ist.

Was für mich gegen TPath spricht:
1. Ich finde nichts was CSIDL_APPDATA verwendet - ah doch GetHomePath indirekt
2. Schlampige Umsetzung (DRY)
3. Verwendet SHGetFolderPath was deprecated sein soll

So scheint Deine Implementation die bessere zu sein. (Abesehen von der Kleinigkeit warum Du nicht IncludeTrailingPathDelimiter verwendest)

Meinungen?

[t2000]

Zitat:

Zitat von freimatz (Beitrag 1462850)

(Abesehen von der Kleinigkeit warum Du nicht IncludeTrailingPathDelimiter verwendest)

Ja, hatte ich nicht dran gedacht. Ist natürlich besser.

Genau weil andere Routinien decrepated sind, habe ich mich dafür entschieden.