FileCreate bei nicht schreibberechtigten Verzeichnissen

Für Fragen zur Programmiersprache auf welcher Lazarus aufbaut
Antworten
Zeff
Beiträge: 7
Registriert: Fr 12. Feb 2016, 21:44
OS, Lazarus, FPC: Winux (Lazarus 2.2.6, FPC 3.2.2)
CPU-Target: 64Bit
Wohnort: Rheinbach

FileCreate bei nicht schreibberechtigten Verzeichnissen

Beitrag von Zeff »

Sorry, dass ich euch mit meinem Beitrag kurz nerven muss.

Es geht hier um die Routine "FileCreate" in den SysUtils von FPC 3.0.0.
Wenn in einem Verzeichnis, für welches keine Schreibrechte bestehen, versucht wird, eine Datei mit "FileCreate"
zu erzeugen, müsste doch dieser Vorgang fehlschlagen. Tut es aber nicht.

Hier ein kleiner Code-Schnipsel:

Code: Alles auswählen

Var
  Err : LongInt;
Begin
  Err := FileCreate('C:\Program Files\Test.tmp');
End;

Ausgabe Err:

Code: Alles auswählen

Writeln(Err)//ergibt 140, also alles klar, was nicht sein darf.

Eigentlich sollte doch "FileCreate" in diesem Fall -1 zurück liefern.

Bei Rewrite macht er es richtig:

Code: Alles auswählen

Var
  Err : Word;
  f   : Text;
Begin
  AssignFile(f,'C:\Program Files\Test.tmp');
  (*$I-*) Rewrite(f); (*$I+*)
  Err := IOResult;
End;

Ausgabe Err:

Code: Alles auswählen

Writeln(Err)//ergibt 2, was richtig ist.

Ist das nun tatsächlich ein Problem bei "FileCreate" oder alles so gewollt?

Zeff

Zeff
Beiträge: 7
Registriert: Fr 12. Feb 2016, 21:44
OS, Lazarus, FPC: Winux (Lazarus 2.2.6, FPC 3.2.2)
CPU-Target: 64Bit
Wohnort: Rheinbach

Re: FileCreate bei nicht schreibberechtigten Verzeichnissen

Beitrag von Zeff »

Ich muss meinen obigen Beitrag zum Teil revidieren.

1.) Mit "keine Zugriffsrechte" meinte ich "keine Schreibrechte". Wurde bereits geändert.

2.) Auch "Rewrite" meldet nun in IOResult eine 0, wenn in einem nicht schreibberechtigten Verzeichnis versucht wird,
eine neue Datei anzulegen. Warum das gestern anders war (IOResult = 2), soll an dieser Stelle erstmal egal sein.

Desweiteren habe ich festgestellt, dass die Testfiles tatsächlich angelegt wurden, aber nicht in "C:\Program Files",
sondern in "C:\Users\USERNAME\AppData\Local\VirtualStore\Program Files". Daraus schließe ich messerscharf, dass Windows
den Vorgang umgeleitet hatte. Stefan Hellmann hat diesen Umstand auf seiner Website sehr gut erklärt, hier der Link:

https://www.pcspinnt.de/2009/11/virtual ... windows-7/

Also, viel Lärm um nichts. Denn schuld ist nicht FileCreate, Rewrite oder FPC, sondern Windows!
Tut mir leid, dass ich euch mit meinem Geschreibsel nerven musste.

Dennoch benötige ich weiterhin eine Routine, die Verzeichnisse auf Schreibbarkeit testet. Aber ich habe schon
ungefähr eine Vorstellung, wie ich mir das zusammenschreibe. Vielleicht wird ein Schuh draus ...

Zeff

jwdietrich
Beiträge: 167
Registriert: Mo 20. Okt 2008, 20:50
OS, Lazarus, FPC: macOS 10.4-13.4, Windows 2000-11, Raspbian (L 2.2.6, FPC 3.2.2)
CPU-Target: PowerPC, Intel, ARM
Wohnort: Hattingen, NRW
Kontaktdaten:

Re: FileCreate bei nicht schreibberechtigten Verzeichnissen

Beitrag von jwdietrich »

In der RTL gibt es fpAccess, eine spezielle Funktion, mit der die Zugriffsrechte einer Datei überprüft werden können.

Warf
Beiträge: 1910
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: FileCreate bei nicht schreibberechtigten Verzeichnissen

Beitrag von Warf »

jwdietrich hat geschrieben:In der RTL gibt es fpAccess, eine spezielle Funktion, mit der die Zugriffsrechte einer Datei überprüft werden können.


Aber nur unter Unioxiden Systemen wie Linux, BSD oder MacOSX

Zeff
Beiträge: 7
Registriert: Fr 12. Feb 2016, 21:44
OS, Lazarus, FPC: Winux (Lazarus 2.2.6, FPC 3.2.2)
CPU-Target: 64Bit
Wohnort: Rheinbach

Re: FileCreate bei nicht schreibberechtigten Verzeichnissen

Beitrag von Zeff »

Richtig, wie Warf schon schrieb, kann ich mit FpAccess unter Windows nichts anfangen.

Mittlerweile habe ich wohl eine Möglichkeit gefunden, wie man Verzeichnisse auf ihre Schreibbarkeit testet, ohne
dabei von Windows auf das VirtualStore-Verzeichnis umgeleitet zu werden. Nach mehreren Versuchen, die fehlschlugen,
blieben noch FileGetAttr und FileSetAttr übrig. Und hier sieht es gut aus. Bleiben wir beim Beispiel mit dem
Verzeichnis "C:\Program Files", welches bekannterweise Leserechte, aber keine Schreibrechte für normale User hat.

Anbei ein Code-Schnipsel in Kurzfassung:

Code: Alles auswählen

Var
  ErrResult : LongInt;
  DirName   : String;
Begin
  DirName := 'C:\Program Files';
  ErrResult := FileGetAttr(DirName);            // Attribute werden nach ErrResult zurückgeliefert.
  ErrResult := FileSetAttr(DirName,ErrResult)// Die gleichen Attribute sollen wieder zurückgeschrieben werden.
  Writeln(ErrResult);                           // Ausgabe: ErrResult = 5 = access denied: Genau das, was wir brauchen,
                                                // denn ein Anlegen einer Datei wird dann auch nicht möglich sein.
  If ErrResult > 0 then Exit;                   // Hier können wir gleich aufhören, denn alles andere bringt nichts mehr.
  // Hier könnte noch Code rein, die im besagten Verzeichnis eine Datei tatsächlich angelegt, nur um ganz sicher zu sein.
  // ...
End;

Bei der Routine FileSetAttr, die eigentlich auch einen Schreibvorgang auslöst, findet seitens Windows keine Umleitung statt.
Das ist für mich erstmal eine Lösung, mit der ich leben kann.

Antworten