tmp bei PBUILD [Erledigt]

[Jan]

Bei meinem Kunden liegen das komplette Alaska-Verzeichnis,VX, alle prg etc. auf dem Server. Ich arbeite also zwar lokal, aber alle Dateien werden beim programmieren über das Netz geschoben. So weit so OK.

Gestern nachmittag sind parallel im Abstand von 3 Minuten beide hochverfügbar geschaltete ESX-Server abgestürzt (vermutlich durch ein Update eines VWare-Tools durch den externen Supporter, beide ESX hatten den netten rosa BlueScreen). Hat ca. 2 Stunden gedauert, bis alles wieder lief. So weit so blöd.

Alles läuft wieder. Aber wenn ich das Hauptprojekt jetzt kompilieren möchte, dann gab das erst zwei oder drei mal irgendwelche Fehlermeldungen wegen lokal nicht erzeugbaren tmp-Dateien. Das ist jetzt zwar weg, aber die erstellte exe ist nicht ausführbar. Nicht mal ein aufzucken. Die exe wird zwar in den entsprechenden Servertools als von mir im Zugriff angezeigt für ein oder zwei Minuten, aber es läuft halt nichts. Die Version von vor dem Servercrash läuft aber einwandfrei. Es liegt also nicht an irgendwelchen DLL oder sowas. Auch die Dateigröße ist absolut korrekt.

Ich habe auch alle .obj etc. gelöscht, damit der wirklich wieder komplett neu aufbaut. Hat leider auch nichts geholfen.

Nachtrag: Ich vergaß zu erwähnen, das ein Kompilieren über einen Remotezugriff auf einen anderen Server geht, der ebenfalls die entsprechenden Laufwerksverknüpfungen hat. Es liegt also eindeutig an dem Client, an dem ich arbeite.

Kann man die Erstellung der zum Kompilieren benötigten tmp umleiten? Oder wo schreibt der Compiler die hin? Ich denke, ich habe alle tmp-Verzeichnisse aufgeräumt, aber irgendwo muß wohl doch noch irgendwas liegen geblieben sein.

Jan

[Tom]

Compiler und Linker nehmen sich das in der Registry bzw. in den Umgebungsvariablen eingestellte Temp-Verzeichnis. Das ist bei Windows 7 und ähnlichen (Server 2008 usw.) c:\Users\<Benutzername>\AppData\Local\Temp - und es handelt sich um ein verstecktes Verzeichnis. Im Explorer heißt das Basisverzeichnis nicht "Users", sondern "Benutzer". Man kann es abfragen, indem man in der Kommandozeile "SET TEMP" eingibt.

[brandelh]

ICH habe für Benutzer und Computer auch unter Win7 auf C:\TEMP umgestellt

[Jan]

Hallo Tom und Hubert,

es gibt ja einen ganzen Schwung an temp-Verzeichnissen. Unter Windows z. B. gibt es ja auch noch welche. Aber alle diese habe ich komplett gelehrt. Und trotzdem laufen die exe nicht, die ich erzeuge. Erzeuge ich die auf dem Remote-Rechner, ist das alles kein Problem. Es muß also sehr sicher etwas mit meinem Rechner zu tun haben.

Jan

[Tom]

Zieh Dir mal den ProcMon von SysInternals auf den fraglichen Rechner und beobachte, worauf Compiler und Linker zugreifen.

www.sysinternals.com

[brandelh]

Hallo Jan,

oben sprichst du einerseits von

"alles liegt auf dem - (Problem)-Server und compiliert wird lokal ...

Also hast du dir die Netzwerklaufwerke von Xbase++ und dem Quellcode auf deinem LOKEN Rechner gemapt und kompilierst mit dem lokalen Rechner ... aber beim zweiten Server ...

"mit gleicher Umgebung ... funktioniert REMOTE compilieren ...

REMOTE ... denke ich gleich an REMOTEDESKTOPVERBINDUNG (oder ähnliches), dabei wird aber gerade NICHT auf dem lokalen Recher kompiliert, sondern auf dem SERVER und du siehst es nur lokal.
Wie genau sieht eigentlich die Fehlermeldung von XPP oder VX oder ? aus ?

CMD Dateien z.B. brauchen ein lokal zugeordnetes Laufwerk (bei RDP ist das dann lokal auf dem SERVER), UNC Namen funktionieren zwar mit vielen Befehlen, aber nicht mit CMD Dateien als solchen.
Eventuell wurden Rechte beim "Reparieren" nicht wieder hergestellt, oder Verzeichnisse fehlen !

[Jan]

Hubert,

eben keine Fehlermeldungen. Das komplilieren läuft vollkommen sauber durch. Aber die exe startet dann nicht. Ohne jedes Zucken.

Ja, das läuft über eine Remotedesktopverbindung. Aber dennoch greift diese auf die selbe Xbase++-Installation zurück wie mein lokaler Client. Daher kann es nichts mit der Installation ansich zu tun haben, sondern es muß irgendwas mit dem Client sein.

Jan

[Jan]

Ich habe die Frage auch an Alaska weitergeleitet. Remote arbeiten geht zwar, ist aber ungemein lästig. Till wußte auch nicht wirklich weiter. Er hat mir dann in einer seinen Mails aber eine neue ALink.exe geschickt. Die ist von März 2010 statt vorher April 2009. Und siehe da - mit der geht das! Die Version geht offenbar toleranter mit den betreffenden Gegebenheiten um, oder korrekter.

Euch beiden vielen Dank für eure Gedanken zu dem Thema.

Jan

[brandelh]

Hallo Jan,

also mußt du die Compilerlaufwerke und/oder die Quellcodelaufwerke gemappt haben, ... ob das wirklich sinnvoll ist ... kann ich nicht entscheiden

Aber hier habe ich was gefunden, Windows 7 trifft meist auch auf neuere Server zu ...

http://www.alaska-software.com/scripts/ ... PDRID=6244

gefixt im HR30 ... wie die Zeit vergeht, 2010 ... und wir warten immer noch =D>