Programm startet nur mit Administratorrechten

[adrian]

Hallo zusammen

Ich habe ähnliche Probleme, bisher bei 3 Kunden von 85.

so wie es aussieht auch immer mit Rechten bei TMP Dateien.

Sogar L&L hat Probleme beim erstellen von Temp-Dateien, mal klappt es mal nicht.

Als Admin absolut keine Probleme. DIes alles seit ca. 2-3 Wochen.

[RolandG]

..wo und wie trägst du das RUN-Verzeichnis in die XPJ ein. TARGET_DIR hat bei mir nicht geholfen.

Die Workbench trägt das in die XPJ bei mir mit zusätzlichen Zeilen so ein:
RunParameter = C:\gs\gsg1_FirmaHFG1.gs
WorkingDir = c:\temp
HostProcess = ..\..\gs\GSG1.EXE

Code: Alles auswählen

[..\exe\GSG1.EXE]
    COMPILE              = xpp
    COMPILE_FLAGS        = /q /m /n /dll:dynamic
    DEBUG_SAVE           = yes
    GUI                  = yes
    LINKER               = alink
    LINK_FLAGS           = /pm:pm
    RC_COMPILE           = arc
    RC_FLAGS             = /v
    RunParameter         = C:\gs\gsg1_FirmaHFG1.gs
    WorkingDir           = c:\temp
    HostProcess          = ..\..\gs\GSG1.EXE
// $START-AUTODEPEND

Das kann man in der Workbench vorgeben unter "Run" + "Parameters"

Die Einträge sind beim normalen pbuild nicht relevant, nur für den Start in der Workbench.
Die Parameter sind auch nicht relevant beim normalen Start in Windows.

[ramses]

ich hatte kürzlich ein ähnliches Problem mit einer Druck-EXE. Ursache war, dass GetEnv("TEMP") auf ein Unterverzeichnis wie C:\Users\...\Temp\16 zeigte, das aber nicht existierte.

Das kenne ich zur genüge. Das kommt wenn es vorkommt nach RDP zugriffen auf den Server vor. Welche Schritte das auslösen habe ich nicht herausgefunden. Abhilfe ist einfach: Eigenen TMP Pfad setzten oder beim Programmstart den Pfad prüfen und ggf. anlegen

Admin rechte waren aber zum Start der EXE nie nötig und diese wurden auch nicht angefordert.

[RolandG]

das mit den TEMP-Verzeichnissen sollte man generell/zentral für seine Xbase++-EXEs lösen. Unkontrolliert gibt das beim Kunden (oder bei einem selbst) Probleme.

Ich habe für mich seit langen Jahren zwei Punkte die ich einrichte/verwende:
1) für alle PCs und Server die ich selbst als zuständiger Admin kontrolliere:
ein generelles, zentrales TEMP Verzeichnis
C:\TEMP
alle Environments, Login-Settings usw. darauf konfiguriert mit allen Rechten für jeden.
(hilft auch beim Bereinigen der Hardware), also keine User-Individuellen Temps.
2) ein generelles TEMP-Verzeichnis für alle meine Xbase++-Programme:
C:\GS\TEMP
In c:\gs liegen lokal alle meine EXE, DLL, INI usw., die DBFs usw. woanders.
Das eigene C:\GS\TEMP wird bei der ersten Nutzung pro Tag 1x geleert.
in meinen EXEs prüfe ich das Vorhandensein von Pkt.2 sonst wird das erstellt.
In diesem Verzeichnis liegen alle von mir generierten, temporären Files. Von allen meinen EXEs die (gleichzeitig) laufen.

[Jan]

Manchmal baue ich mir mein eigenes temporäres Verzeichnis. Aber meistens gehe ich in das Windows-Temp-Verzeichnis, das ich mit GetEnv("TEMP") auslese. Manchmal lege ich dann darin ein Unterverzeichnis für mich an, das ich dann bei Bedarf wieder sauber löschen kann.

Bislang hatte ich damit noch nie Probleme, auch nicht bei den Kunden.

Jan

[azzo]

Jan, dein Ansatz funktioniert in >90 % der Fälle stabil, aber nicht in allen Windows-Kontexten, da GetEnv("TEMP") ein logischer Pfad ist – nicht garantiert ein existierender.
Um das abzusichern, musst du immer auch prüfen:

Code: Alles auswählen

IF !Directory(GetEnv("TEMP"))
   // Fehlerbehandlung oder MakeDir() mit übergeordnetem Pfad
ENDIF

[Jan]

Otto,

wie ich schrieb passt es bislang bei mir immer.

Das hindert ja nicht das vorsichtshalber noch mal wie in Deinem Beispiel zu prüfen.

Wobei sich mir die Frage stellt ob Windows nicht irgend welche Mechanismen hat, selber die Existenz dieses Verzeichnisses sicherzustellen. Immerhin schreiben alle möglichen Prozesse da ihre Daten rein, das ist für Windows überlebenswichtig.

Jan