tmp bei PBUILD [Erledigt]
Moderator: Moderatoren
- Jan
- Marvin
- Beiträge: 14651
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
tmp bei PBUILD [Erledigt]
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
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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9356
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: tmp bei PBUILD
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.
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15695
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: tmp bei PBUILD
ICH habe für Benutzer und Computer auch unter Win7 auf C:\TEMP umgestellt
Gruß
Hubert
Hubert
- Jan
- Marvin
- Beiträge: 14651
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: tmp bei PBUILD
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
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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9356
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: tmp bei PBUILD
Zieh Dir mal den ProcMon von SysInternals auf den fraglichen Rechner und beobachte, worauf Compiler und Linker zugreifen.
www.sysinternals.com
www.sysinternals.com
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15695
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: tmp bei PBUILD
Hallo Jan,
oben sprichst du einerseits von
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 !
oben sprichst du einerseits von
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 ..."alles liegt auf dem - (Problem)-Server und compiliert wird lokal ...
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."mit gleicher Umgebung ... funktioniert REMOTE compilieren ...
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 !
Gruß
Hubert
Hubert
- Jan
- Marvin
- Beiträge: 14651
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: tmp bei PBUILD
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
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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Jan
- Marvin
- Beiträge: 14651
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: tmp bei PBUILD
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
Euch beiden vielen Dank für eure Gedanken zu dem Thema.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- brandelh
- Foren-Moderator
- Beiträge: 15695
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: tmp bei PBUILD [Erledigt]
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>
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>
Gruß
Hubert
Hubert