Ini-Datei Zugriff verweigert

Pechvogel · Hält's aus hier Beiträge: 5

Guten Abend zusammen

Hab eine Frage:

Seit längerem kann ich nicht nehr in meine ini-Dateien schreiben.
Es kommt die Meldung: kann nicht nach ----> der spezifischen INI-Datei schreiben.
Ein Schreibschutz ist bei der betreffenden INI-Datei nicht gesetzt.

Hab ein weiteres Problem mit dem Schreibschutz von Windows XP:

Ich kann bei den Ordnern den Schreibschutz entfernen mit der normalen Ordner Eigenschaften Option.
Sobald die Prozedur abgeschlossen ist, ist ein viereckiges Füllfeld auf dem Schreibschutz gesetzt.
Der Schreibschutz wurde also nicht entfernt.

Vielleicht hat jemand eine Lösung für diese Probleme.
Ich danke Euch im voraus für die Lösungsansätze.

Viele Grüsse

Pechvogel

jaenicke · Verfasst: Fr 21.03.14 22:11

Hallo und

Pechvogel hat folgendes geschrieben :

Es kommt die Meldung: kann nicht nach ----> der spezifischen INI-Datei schreiben.
Ein Schreibschutz ist bei der betreffenden INI-Datei nicht gesetzt.

Ohne Quelltext und ein wenig mehr Infos wird dir da niemand helfen können.
Wichtig ist dabei eigentlich nur, dass man die INI nach dem Zugriff auch wieder freigibt und dass man die INI nicht in das Verzeichnis versucht zu schreiben, in dem die Exe liegt, sondern in die Anwendungsdaten.

Pechvogel hat folgendes geschrieben :

Ich kann bei den Ordnern den Schreibschutz entfernen mit der normalen Ordner Eigenschaften Option.
Sobald die Prozedur abgeschlossen ist, ist ein viereckiges Füllfeld auf dem Schreibschutz gesetzt.
Der Schreibschutz wurde also nicht entfernt.

Ordner haben keinen Schreibschutz, den haben nur Dateien, deshalb gibt es da auch nichts zu entfernen. Deshalb sieht die Anzeige auch so aus.

Delphi-Laie · Verfasst: Sa 22.03.14 11:13

jaenicke hat folgendes geschrieben :

Ordner haben keinen Schreibschutz, den haben nur Dateien, deshalb gibt es da auch nichts zu entfernen.

In z.B. Windows XP kann man mit Rechtsklick auf ein Verzeichnissymbol die Eigenschaften aufrufen und gelangt dort zum Reiter "Sicherheit", wo man die Berechtigungen einstellen kann.

Pechvogel · Hält's aus hier Beiträge: 5

Guten Tag

Besten Dank fuer Eure Antworten.
Ja, die INI-Datei befindet sich in dem Verzeichnis, wo die EXE-Datei ist.
Aber ich hatte ja bis anhin keine Probleme. Das spricht nicht dafür, dass ich
alles ändern muss. Es muss an etwas anderem liegen.

Den Quelltext kann ich nachfolgend noch beifügen, wenn das helfen sollte:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:

procedure TMain.SaveToIni2(Inipath, IniSection : string);
var
  IniFile : TIniFile;
  d,b: string;
begin
  IniFile:=TIniFile.Create(Inipath);
  try
  d:=dbedit12.text;
  b:=dbedit1.text;
  IniFile.WriteString('Strings', 'AAAAA', d);
  IniFile.WriteString('Strings', 'BBBBB', b);
  finally
  IniFile.Free;
  end;
end;

Das INI-File wird ja freigegeben mit der Programmierzeile: IniFile.Free

Vielleicht hat sonst noch jemand einen Lösungsansatz.

Moderiert von Martok: Delphi-Tags hinzugefügt

jaenicke · Verfasst: Sa 22.03.14 12:08

Zum eigenen Verzeichnis:
www.delphi-library.d...ewtopic.php?p=548600

Was ist denn Inipath? Ist da auch der komplette Pfad drin?
Wenn nicht:
www.delphi-library.d...ewtopic.php?p=499701

Pechvogel · Hält's aus hier Beiträge: 5

Guten Tag

Danke für die Frage:

Ja, Inipath ist ein String, wo der Weg drin ist. Den hol ich mit:
inipath := extractfilepath(application.exename);

Gruss

Pechvogel

jaenicke · Verfasst: Sa 22.03.14 16:43

Du meinst hoffentlich du hängst danach noch den Dateinamen an, oder? Sonst fehlt der nämlich.

D.h. dein Programm ist ein portables Programm und liegt somit nie unter c:\programme? Dann ist das soweit eigentlich alles richtig.

Kannst du das in einem Testprojekt reproduzieren, das du uns hier anhängen kannst?

Ansonsten bliebe noch der Process Monitor um zu schauen was da eigentlich passiert.

Tranx · Verfasst: Sa 22.03.14 19:55

Pechvogel hat folgendes geschrieben :

Guten Tag

Danke für die Frage:

Ja, Inipath ist ein String, wo der Weg drin ist. Den hol ich mit:
inipath := extractfilepath(application.exename);

Wenn Du in der Variablen Inipath nur das Verzeichnis der Programmdatei (mit ExtractFilePath) ausgibst, kann das nicht klappen. Du musst ja mindestens noch den Dateinamen anhängen:

markieren

Delphi-Quelltext

1:	inipath := extractfilepath(application.exename)+ 'Inidatei.ini'; // hier den Dateinamen ergänzen, den Du wählst.

_________________
Toleranz ist eine Grundvoraussetzung für das Leben.

Pechvogel · Hält's aus hier Beiträge: 5

Zu Deiner Frage: inipath

Danke für die Frage:

Ja, Inipath ist ein String, wo der Weg drin ist. Den hol ich mit:
inipath := extractfilepath(application.exename);

[/quote]

Wenn Du in der Variablen Inipath nur das Verzeichnis der Programmdatei (mit ExtractFilePath) ausgibst, kann das nicht klappen. Du musst ja mindestens noch den Dateinamen anhängen:

markieren

Delphi-Quelltext

1:	inipath := extractfilepath(application.exename)+ 'Inidatei.ini'; // hier den Dateinamen ergänzen, den Du wählst.

[/quote]

Also ich speichere die Inidatei wie folgt:

savetoini2(inipath+ 'XXXXX.INI', 'Werte');

und lade mit:

loadfromini2(inipath+ 'XXXXX.INI', 'Werte');

Also muss ich in der Prozedur keinen Namen definieren.
inipath + 'Filenamen' -----> ergibt den gesamten Pfad mit Dateinamen an.

Das hat immer geklappt.

Danke für die Frage, aber mein Speicherproblem ist immer noch offen.

Gruss

Pechvogel

jaenicke · Verfasst: Mo 24.03.14 06:29

Bleiben noch die Punkte, die ich noch genannt hatte. ;-)

jaenicke hat folgendes geschrieben :

D.h. dein Programm ist ein portables Programm und liegt somit nie unter c:\programme? Dann ist das soweit eigentlich alles richtig.

Kannst du das in einem Testprojekt reproduzieren, das du uns hier anhängen kannst?

Ansonsten bliebe noch der Process Monitor um zu schauen was da eigentlich passiert.

Im Process Monitor musst du nur in dem Filterfenster, das nach dem Start aufgeht, eintragen "Process Name" "is" "DeineExe.exe". Daraufhin siehst du alles was die macht.
Dann startest du die, lässt die Fehlermeldung stehen und schaust was als letztes im Process Monitor zu sehen ist. Das wird irgendetwas mit der INI sein. Das kannst du gerne auch hier posten, wenn du damit nichts anfangen kannst. (Zum Beispiel indem du das Log mit File --> Save speicherst, am besten mit "Events displayed using the current filter" und "Native Process Monitor Format (PML)" im Speicherdialog aktiviert.)

icho2099 · Verfasst: Mo 24.03.14 08:01

Mein D6 liefert bei ExtractFilePath() nur den Pfad ohne Backslash am Ende.
IncludeTrailingBackslash(ExtractFilePath)) + 'xxxxxx.ini' könnte helfen.

jaenicke · Verfasst: Mo 24.03.14 12:24

Das war dann dort ein Fehler. Path ist mit Trennzeichen, Dir ohne (außer bei Rootverzeichnis).

WasWeißDennIch · Beiträge: 653 Erhaltene Danke: 160

Aber es ist auch kein Fehler, generell mit IncludeTrailingPathDelimiter (oder IncludeTrailingBackslash) auf der sicheren Seite zu bleiben.

jaenicke · Verfasst: Mo 24.03.14 14:50

Falsch sicherlich nicht, nur unnötig. Solange man das nicht öfter aufruft, merkt man den Unterschied allerdings auch nicht, da ist es egal.

Nersgatt · Verfasst: Mo 24.03.14 15:16

Ich finde das komisch. Überall wird sich drauf verlassen, dass die Funktionen der RTL/VCL das tun, was sie tun sollen. Erst wenn sie es nicht tun, überlegt man sich, ob man das Problem umschiffen kann.
Aber bei ExtractFilePath und Konsorten wird mit IncludeTrailingPathDelimiter nur so um sich geworfen. Nach dem Motto: sicher ist sicher. :roll:

Das sehe ich in Quellcodes immer und immer wieder. Und ich verstehe nicht, warum das gemacht wird. Es ist unnötig, verschwendet Rechenzeit und macht den Code schlechter lesbar.

Genauso wie ich nicht verstehe, dass man immer wieder solche Konstruktionen bei TDataSet-Nachkömmlingen sieht:

markieren

Delphi-Quelltext

1:	if not ds.Active then ds.Active := True;

Ist genauso doppelt gemoppelt, nach dem Motto "sicher ist sicher", da der Setter von Active nur ausgeführt wird, wenn das DataSet nicht schon Active = True ist.

Oder ein weiteres Beispiel, oft gesehen: if Assigned(bla) then bla.Free
Ein Blick in den Quellcode von .Free hätte einem zur Erkenntnis geführt, dass man sich die Abfrage auf Assigned sparen kann.

_________________
Gruß, Jens
Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du. (Mahatma Gandhi)

Pechvogel · Hält's aus hier Beiträge: 5

Guten Abend oder guten Morgen

Hab Eure Nahrichten gelesen.
Habt Dank fuer Eure "gut gemeinten" Ratschläge.
Aber mein Problem mit der INI-Datei ist leider immer noch nicht gelöst.
Ihr habt Euch verloren in Diskussionen um Punkte, die nichts mit meinem
Thema zu tun haben.
Fakt ist, dass ich mit meiner Procedure, die ich ja angegeben habe,
einwandfrei Daten in die INI-Datei schreiben konnte.

Gruss

Pechvogel

jaenicke · Verfasst: Do 03.04.14 06:53

Deshalb hatte ich ja auch vorgeschlagen, dass du mit dem ProcessMonitor schauen kannst was da passiert. (Mit Filter gesetzt auf "Path" "ends with" "deineini.ini")
Vielleicht wird sie schon woanders in deinem Programm geöffnet, vielleicht ist der Pfad falsch, ...

Ohne das Problem selbst zu sehen, können wir nicht viel analysieren. Denn der Quelltext, soweit du ihn gepostet hast, ist ja korrekt.

Wenn du selbst mit dem Log des Process Monitors nichts anfangen kannst, kannst du das auch gerne hier posten. (Dann bitte das Loggen stoppen (Lupensymbol oder Strg + E) sobald die Fehlermeldung angezeigt wird und bevor du sie bestätigst. Speichern mit "Events displayed using current filter", damit es nicht zu groß wird, und im PML Format.)

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme