Service-Anwendung und assignfile

[speedy]

Hi,

hab mich mal an einer Service-Anwendung versucht und stehe vor folgendem Problem:

Versuche eine normale Textdatei zu öffnen und daraus zu lesen:

Delphi-Quellcode:

assignfile(f,'test.txt');
reset(f);
// sonstiger code
closefile(f);

die test.txt existiert natürlich im gleichen Verzeichnis wie die Anwendung. Der Service beendet sich, wenn dieser Code vorkommt.
Auch den kompletten Pfad wie z.B. c:\test.txt nimmt er nicht.

Wenn ich allerdings eine neue Datei anlege mit

Delphi-Quellcode:

assignfile(f,'test.txt');
rewrite(f);
// sonstiger code
closefile(f);

dann funktioniert alles ohne Probleme.

Jemand ne Idee?

Gruß
speedy

[Bummi]

klingt nach einem Rechteproblem, wobei ich mich nicht auf den Pfad der Anwendung verlassen würde, auf "C:\datei.ext" darf ein Normaluser seit Vista auch nicht mehr ohne weiteres.

[mkinzler]

Unter welchem Nutzer läuft den der Dienst?

[speedy]

Der Dienst läuft laut Taskmanager als System.

[Luckie]

Und?mhat deas Benutzerkonto System die nötigen Zugriffsrechte?

[speedy]

Windows sagt mir zumindest in den erweiterten Sicherheitseinstellungen der entsprechenden EXE, dass das System Vollzugriff hat, oder gibts da noch irgendwo ne andere Möglichkeit die Rechte des System Accounts zu ändern? In den Konteneinstellungen wird System ja gar nicht erst angezeigt.

[Bummi]

Nimm doch testweise einen unpreviligierten Ordner mit einem harten Pfad der exisistiert (z.B. C:\test\test.txt).

Ändere den Dienstaccount versuchsweise auf ein Administratives Konto.

Versuche die Fehlermeldung abzugreifen (GetLasterror), oder zu debuggen (hierbei ist es hilfreich ein Sleep(10000)) am Anfang einzubauen und nach dem Dienststart in Delphi "mit Prozess verbinden aufzurufen"

[wicht]

Zitat:

Windows sagt mir zumindest in den erweiterten Sicherheitseinstellungen der entsprechenden EXE, dass das System Vollzugriff hat

Das heißt aber nur, dass das System-Konto auf die .exe Vollzugriff hat - aber nicht auf die zu erstellende Datei (bzw. das Verzeichnis, in dem sie erstellt werden soll).

[Sir Rufo]

Warum fängst du an der Stelle nicht mal die Exception ab?
(dann würde sich dein Service auch nicht ins Nirwana verabschieden)
Hängt allerdings auch von dem Compilerschalter

Delphi-Quellcode:

{$I+}

ab
http://docwiki.embarcadero.com/VCL/XE/de/System.Reset

Delphi-Quellcode:

assignfile(f,'test.txt');
  try
    reset(f);
    // sonstiger code
  except
    on E: Exception do
      SchreibInMeinLog( E.Message );
  end;
closefile(f);

Ansonsten würde ich immer folgendes Konstrukt vorschlagen:

Delphi-Quellcode:

assignfile( f, 'test.txt' );  // Zu sehen wie ein Object := TObject.Create
try
  {$I-}
  reset( f );
  {$I+}
  if IOResult = 0 then
    begin
      // sonstiger code
    end;
finally
  closefile( f );  // Zu sehen wie ein Object.Free
end;

[Bummi]

wobei spätestens hier das nächste Problem auftreten wird.:wink:

Delphi-Quellcode:

SchreibInMeinLog

[speedy]

Okay ;)

Das schau ich mir morgen mal genauer an wie das mit Service-Anwendung debuggen funktioniert. Ist das erste Mal, dass ich mich an nem Dienst versuche...

[Sir Rufo]

Zitat:

Zitat von Bummi (Beitrag 1061783)

wobei spätestens hier das nächste Problem auftreten wird.:wink:

Delphi-Quellcode:

SchreibInMeinLog

Warum sollte?

Zitat:

Zitat von speedy (Beitrag 1061672)

Wenn ich allerdings eine neue Datei anlege mit

Delphi-Quellcode:

assignfile(f,'test.txt');
rewrite(f);
// sonstiger code
closefile(f);

dann funktioniert alles ohne Probleme.

[Luckie]

Der else-Zweig mit der Fehlerbhandlung fehlt bei dir noch, sonst macht es keinen Sinn.

[Bummi]

@Sir Rufo
sorry, hatte ich übersehen...

[Sir Rufo]

Zitat:

Zitat von Luckie (Beitrag 1061788)

Der else-Zweig mit der Fehlerbhandlung fehlt bei dir noch, sonst macht es keinen Sinn.

Wieso sollte es keinen Sinn machen? Kommt auf den Sinn an, den ich vorhabe :mrgreen:

[Luckie]

Wir wollen doch wissen, warum es nicht klappt.

[Sir Rufo]

Zitat:

Zitat von Luckie (Beitrag 1061797)

Wir wollen doch wissen, warum es nicht klappt.

Mein Beispiel war ja nur dafür, wie man eigentlich generell mit AssignFile/CloseFile umgehen sollte. Das Abfangen/Protokollieren des Fehlers habe ich ja davor aufgeführt.

Die weitere Ausschmückung bleibt jedem selber überlassen. Generell würde ich einfach nur das AssignFile/CloseFile wie Object := TObject.Create/Object.Free immer in einem try..finally Block einschliessen.

Sozusagen die Basic-Rules, ähnlich wie

Zitat:

Randomize gehört an den Anfang der dpr-Datei und nirgend woanders hin

Delphi-Quellcode:

program foo;
{...}
begin
  Randomize;
  {...}
end.

[speedy]

So, habs hinbekommen den Debugger laufen zu lassen... :stupid:

"Im Projekt Project1.exe ist eine Exception der Klasse EInOutError mit der Meldung 'Datei nicht gefunden' aufgetreten."

Die Datei ist aber zweifelsfrei im gleichen Pfad wie die .exe vorhanden.

Pfad des Projekts ist hierbei in einem Unterordner von Dokumente des aktuellen Benutzers (Admin Account unter Win7 x64). Der Dienst läuft hierbei als Localsystem.

Mit einem absoluten Pfad z.B. c:\test.txt funktionierts jetzt plötzlich. Keine Ahnung warum, aber gestern ging es auch damit nicht.

Frage wäre jetzt noch warum Windows die Datei nicht findet, wenn eben kein absoluter Pfad angegeben wird...

[mkinzler]

Weil relative Pfade relativ zum Arbeitsverzeichnis sind, welches nicht unbedingt das Verzeichnis sein muss, in dem die Exe liegt. Deshalb realtive Pfade dynamisch als vollständige absolute Pfade zusammensetzen

[s.h.a.r.k]

Schau dir mal Windows-Verknüpfungen an. Dort gibt es unter Eigenschaften ein Feld namens "Ausführen in:". Damit kannst du den lokalen Kontext, also den Ort an dem die Exe ausgeführt wird einstellen. D.h. nicht jede Anwendung muss in dem Verzeichnis ausgeführt sein, indem Sie liegt. Somit sind relative Pfade immer mit Vorsicht zu genießen.

-- EDIT1: No red box...
-- EDIT2: Vielleicht hilft dir ja

Delphi-Quellcode:

ExtractFilePath(Application.ExeName)

weiter. Das sollte dir den Pfad liefern, in dem die Exe-Datei liegt.

[Bummi]

Zitat:

Pfad des Projekts ist hierbei in einem Unterordner von Dokumente des aktuellen Benutzers (Admin Account unter Win7 x64).

Wahrscheinlich der denkbar schlechteste Ort ...
Nimm, doch einen sinnvollen Ordner und wenn Anwendung und Datei im gleichen Ordner liegen müssen greife per
ExtractFilePath(Application.Exename)+'wieauchimmer .txt' zu.

[Luckie]

Über leg doch mal. Du steht in einer Bibliothek, in der du dich nicht auskennst, und sollst ein Buch holen. Sagen wir das Buch "Raise and Fall of the Roman Empire". Wenn dir jemand sagt: "Gehe in Raum 3, Abteilung 5, Regal 11, unterstes Regalbrett, dritte Buch von links: "Raise and Fall of the Roman Empire". Wie wirst du das Buch eher finden, wenn du nicht zufällig genau davor stehst, nur alleine mit dem Titel oder mit der kompletten Angabe wo das Buch steht? Genauso geht es Windows auch. Wenn das Arbeitsverzeichnis nicht zufällig, das Verzeichnis mit der gewünschten Datei ist, wird Windows die Datei nicht finden.

Und dass das gestern nicht geklappt hat, könnte an einem anderen Fehler im Programm gelegen haben.

PS: Mir ist leider kein passender Autoindustrievergleich eingefallen. ;)

[mkinzler]

Oder

Delphi-Quellcode:

ParamStr(0)

, dann wird die Unit Forms nicht benötigt (Application.Exename verwendet ParamStr(0))

[speedy]

Alles klar ;)
Danke!

[Sir Rufo]

Zitat:

Zitat von mkinzler (Beitrag 1062070)

Weil relative Pfade relativ zum Arbeitsverzeichnis sind, welches nicht unbedingt das Verzeichnis sein muss, in dem die Exe liegt. Deshalb realtive Pfade dynamisch als vollständige absolute Pfade zusammensetzen

Und gerade ein Service hat als Arbeitsverzeichnis nicht das Anwendungsverzeichnis ;)

Ich würde auf

Delphi-Quellcode:

Application.Exename

verzichten und dafür

Delphi-Quellcode:

ParamStr( 0 )

verwenden. Für den Zugriff auf

Delphi-Quellcode:

Application

benötigt man die Unit Forms und die hat gerade in einer Service-Anwendung nun gar nichts verloren ;)

Weiterhin würde ich generell in das Programmverzeichnis nicht schreibend zugreifen (Ausnahme bei der Installation). Abgesehen davon, dass das meistens eh nicht geht (fehlende Rechte) finde ich es als äusserst störend bei einer Deinstallation noch Dateileichen vorzufinden, weil der Uninstaller per Default dass Programmverzeichnis nur dann löscht, wenn es leer ist.

Es gibt schließlich genug Verzeichnisse, die dafür vorgesehen sind und wo ich auch weiß, aha, Programm ist weg, will ich nicht mehr, dann können die Daten auch weg.

[mkinzler]

Zitat:

Ich würde auf Application.Exename verzichten und dafür ParamStr( 0 ) verwenden. Für den Zugriff auf Application benötigt man die Unit Forms und die hat gerade in einer Service-Anwendung nun gar nichts verloren

http://www.delphipraxis.net/1062075-post23.html

[Sir Rufo]

Zitat:

Zitat von mkinzler (Beitrag 1062081)

Zitat:

Ich würde auf Application.Exename verzichten und dafür ParamStr( 0 ) verwenden. Für den Zugriff auf Application benötigt man die Unit Forms und die hat gerade in einer Service-Anwendung nun gar nichts verloren

http://www.delphipraxis.net/1062075-post23.html

Bei mir steht aber noch, dass die Unit Forms in einer Service-Anwendung nichts verloren hat :mrgreen:

[mkinzler]

Stimmt, ganz so deutlich habe ich das nicht erwähnt

[Sir Rufo]

Zitat:

Zitat von mkinzler (Beitrag 1062083)

Stimmt, ganz so deutlich habe ich das nicht erwähnt

:cheers: