ini Datei ohne admin zu sein

[yogie]

Hallo zusammen,

mein Programm verwendet INI-Dateien. Beim Schließen des Programms
(onClose der Main-Form) werden einige INI Daten geschrieben. Das klappt alles
problemlos, solange das Programm mit Administrator-Rechten läuft. Sobald
es ohne Administrator-Rechte läuft gibt es Probleme. Die INI Daten werden beim
Schließen sauber geschrieben, ich kann die Datei hinterher kontrollieren.
Danach meldet das Programm aber einen Fehler beim Schreiben der INI-Datei.

Die Fehlermeldung verweist auf eine Datei „program.ini“. Ich habe dann den von mir erzeugten Namen der Ini-Datei in „program.xxx“ verändert. Die Fehlermeldung verweist
aber immer noch auf „program.ini“. Es ist sichergestellt, das Schreibrechte für das Verzeichnis bestehen. Ich habe das gesamte Programm nach übersehenen Schreibbefehlen durchsucht und nichts weiter gefunden. Alle Zugriffe auf INI-Dateien sind in einer zentralen UNIT zusammengefaßt.

Hat jemand einen Tip?

[jaenicke]

Wohin schreibst du die denn? In das Verzeichnis deiner .exe wie bei Windows 9x? Das ist seit mehr als 10 Jahren ein Programmierfehler (von ganz wenigen Ausnahmen mal abgesehen).
Mehr dazu habe ich hier geschrieben:
http://www.delphi-library.de/viewtopic.php?p=548600

Was dein konkretes Problem angeht:
Das solltest du beim Debuggen doch merken wo der Fehler auftritt. :gruebel:

Wenn das auf deinem PC nicht passiert, bleiben nur Meldungen der Art "OnClose Beginn", "OnClose Ende" usw. um festzustellen wo das passiert.

[Sir Rufo]

Die einzige Ausnahme die ich kenne, ist eine grundlegende, sich nach der Installation nicht ändernde Konfigurationsdatei, auf die dann auch nur lesend zugegriffen wird ;)

[yogie]

@jaenicke
ich lasse mir das APPDATA Verzeichnis geben

{uses Shlobj für CSIDL_APPDATA; glDefaultPath in QVC_global}

glDefaultPath := GetSpecialFolder(CSIDL_APPDATA) + '\Firma\';
if not DirectoryExists(glDefaultPath) then
MkDirEx(glDefaultPath); {erzeugt ev. nicht vorhandenes DIR}

und lege dort ein Unterverzeichnis an. Das klappt auch.

[Blup]

Eventuell liegt der Fehler an der Stelle wo die "program.ini" gelesen wird.
Wird das File dort auch mit Nur-Lesen geöffnet?
Wird das File auch wieder ordentlich geschlossen, bzw. freigegeben?

[Sir Rufo]

Zitat:

Zitat von yogie (Beitrag 1224705)

@jaenicke
ich lasse mir das APPDATA Verzeichnis geben

Delphi-Quellcode:

    {uses Shlobj für CSIDL_APPDATA; glDefaultPath in QVC_global}

    glDefaultPath := GetSpecialFolder(CSIDL_APPDATA) + '\Firma\';
    if not DirectoryExists(glDefaultPath) then
      MkDirEx(glDefaultPath); {erzeugt ev. nicht vorhandenes DIR}

und lege dort ein Unterverzeichnis an. Das klappt auch.

Auch das AppData-Verzeichnis ist default nicht zum Schreiben für jedermann bereit, sondern muss im Rahmen der Installation dafür vorbereitet werden.

Halt, Kommando zurück, das war CSIDL_COMMON_APPDATA :)

BTW: Bitte nutze für Delphi-Code auch die

Code:

[DELPHI][/DELPHI]

Tags

[Bjoerk]

Wenn es nicht an den Schreibrechten liegt. Versuchen mehrere Formulare/ Klassen beim Beenden der App was in die INI zu schreiben?

[jaenicke]

Zitat:

Zitat von yogie (Beitrag 1224700)

Danach meldet das Programm aber einen Fehler beim Schreiben der INI-Datei.

Wie lautet der Fehler denn? Zugriffsfehler, schon geöffnet, ...?
Und an welcher Stelle im Code kommt der?
Das müsstest du ja wie schon geschrieben im Debugger sehen.

[Dalai]

Zitat:

Zitat von Sir Rufo (Beitrag 1224712)

Auch das AppData-Verzeichnis ist default nicht zum Schreiben für jedermann bereit [...]

Nicht für jedermann, aber natürlich ist es ohne weitere Maßnahmen für den Benutzer schreibbar, der das Programm gerade benutzt. Der einzige Unterschied zwischen APPDATA und LOCAL_APPDATA ist, dass letzteres kein Bestandteil der Roaming Profiles ist, also in einer Domäne nicht automatisch auf den Server synchronisiert wird. Schreibbar sind aber beide für den jeweiligen Nutzer.

Aber ich sehe gerade, du hast deinen Irrtum bemerkt 8-).

MfG Dalai

[yogie]

Zitat:

Zitat von Bjoerk (Beitrag 1224713)

Wenn es nicht an den Schreibrechten liegt. Versuchen mehrere Formulare/ Klassen beim Beenden der App was in die INI zu schreiben?

nein, das macht nur das Hauptformular. Ich habe einen Breakpoint in meiner
zentralen Unit für das Screiben in die INI-Datei gesetzt und den Programmablauf
(als Admin) verfolgt. Es gibt keinen versteckten Zugriff auf die INI.

[yogie]

Zitat:

Zitat von jaenicke (Beitrag 1224717)

Zitat:

Zitat von yogie (Beitrag 1224700)

Danach meldet das Programm aber einen Fehler beim Schreiben der INI-Datei.

Wie lautet der Fehler denn? Zugriffsfehler, schon geöffnet, ...?
Und an welcher Stelle im Code kommt der?
Das müsstest du ja wie schon geschrieben im Debugger sehen.

da habe ich gerade mein Problem so (dusselig) wie der PC eingerichtet
ist, kann ich als nicht Ademin mein Delphi nicht verwenden. Da ist wohl
etwas Arbeit angesagt ...

Aber trotzdem erstmal danke für die Hinweise

[DeddyH]

Wer hat denn gesagt, dass Du Delphi als Admin ausführen sollst? Nenn doch einfach die Fehlermeldung, dann sind wir vermutlich bereits schlauer.

[jaenicke]

Zitat:

Zitat von DeddyH (Beitrag 1224736)

Wer hat denn gesagt, dass Du Delphi als Admin ausführen sollst? Nenn doch einfach die Fehlermeldung, dann sind wir vermutlich bereits schlauer.

Umgekehrt, das Delphi läuft nicht ohne Admin...
Vielleicht noch UAC deaktiviert... das sind die besten Entwickler-PCs... :roll:
Aber es ist halt wie es ist im Moment. ;-)

Deshalb dieser Vorschlag:
Shift + rechte Maustaste auf die Exe, Als anderer Benutzer ausführen, Benutzer ohne Adminrechte nehmen, dann in Delphi Start --> Mit Prozess verbinden, auswählen, fertig, schon debuggst du. ;-)

[yogie]

Hallo zusammnen,

nochmal vielen Dank für die Tips, habe wieder viel gelernt.
Das Problem war ein ganz anderes.

Den Namen der INI-Datei habe ich immer aus dem EXE-Namen abgeleitet
und dann ein passendes Verzeichnis mit! Schreibrechten gesucht (s.o.)

Die Fehlermeldung kam aber nicht aus "meinen" Aktionen mit der INI-Datei.
Ich habe noch eine Komponente für die Speicherung der MRU-Files. Die speichert
auch in einer INI-Datei und hat auch den Namen aus dem EXE-Namen abgeleitet.
In der Komponete wurde aber immer ins Installations-Verz. geschrieben, das ging
dann bei einer Verwendung ohne Admin-Rechte schief.

So ... Feierabend!