Problem mit dem Spoolverzeichnis

PDFCreator PDFCreator German
1

Hallo zusammen,

ich stehe bei einem Kunden vor dem Problem, dass der PDF Creator 1.3.2 anscheinend ein Problem
mit dem Spoolverzeichnis hat. Das Problem tritt dann auf, wenn aus einem anderen Programm über
Visual Baisc der PDFCreator direct angesprochen wird. Der PDFCreator ist dabei auf einem
Windows 2008 R2 Terminalserver in der Standardversion installiert.
Folgendes ist uns dabei aufgefallen:

1. Druckt man z.B. eine Textdatei ganz normal über PDFCreator aus, erstellt der PDFCretor sein Spoolverzeichnis unter dem folgendem Pfad: "C:\\Users\\\\AppData\\Local\\Temp\\PDFCreator\\Spool\\" .
Sieht man sich die Systemvariable Temp an, dann lautet die aber wie erwartet auf :
"C:\\Users\\\\AppData\\Local\\Temp\\\\".
Dieses stellt für den normalen Druck auch keien Problem dar, da der Monitor die Spooldateien ja
ebenfalls unter "C:\\Users\\\\AppData\\Local\\Temp\\PDFCreator\\Spool\\" sucht und findet.

2. Wird aus der Anwednung heraus auf den PDFCreator gedruckt, dann erstellt der PDFCreator das
Spoolverzeichnis dagegen unter dem Pfad der zur Systemvariable Temp passt, also  "C:\\Users\\\\AppData\\Local\\Temp\\\\PDFCreator\\Spool\\" .
Dieses Verzeichnis ist aber dem Monitor nicht bekannt, und er kann die gespoolten Dateien nicht
auflisten.

Der Programmierer der Anwendung, sagt mri, dass er keinen Spoolpfad in seienr Programmierung
vorgibt, sondern nur direkt auf das Objekt PFCreator druckt. Wird der PDFCreator auf einem
normalen PC mit Windows XP installiert, läuft alles problemlos, allerdings hat man dort auch nicht
die Sitzungsnummer im Verzeichnispfad drinstehen.

3. Der Versuch den Spoolpfad über die Variable PrinterTempPath umzulegen, brachte keinen Erfolg.
Die Variable wird vollständig ignoriert, man kann eintragen was man will, PDFCreator spoolt immer
unterhalb des Temp Verzeichnisses.

Für mich sieht es so aus, als ob hier noch ein Bug vorliegt, warum erstellt der PDFCreator sein Spoolverzeichnsi
an unterschiedlichen Stellen, jenachdem ob ein normaler Ausdruck erfolgt, oder eine programmgesteuerter ?
 

Bin für jede Hilfe dankbar, da aktuell ziemlich ratlos.

Gruß Christian  

2

Hallo Frank,

eben  unter "Open Discussion" gefunden. ist das gleiche Problem, aber mit Hinweis auf VB6.
Vielleicht hilft es Euch bei der Fehlersuche.

Gruß Christian

 

 

3

Hier noch der Link: http://www.pdfforge.org/forum/open-discussion/8593-bug-terminal-serveur-2008-r2

4

Habe eben in einem anderen Thread gelesen, dass seit Version 1.3.0 das Spoolverzeichnis automatisch im Userprofilpfad angelegt wird, bedeutet dieser Umstand dann gleichzeitig, dass der Registryeintrag PrinterTemppath keine Funktion mehr hat ?

Wenn dem so ist, wie wird der Pfad zum Spoolverzeichnis ermittelt ?

Geschieht dies mit Hilfe der Variable %USER% ? Das würde erklären, warum das Spoolverzeichnis immer unter ..\\AppData\\Local\\Temp\\PDFCreator liegt, und die Sitzungsnummer die beim eigentlichen Tempverzeichnis laut %TEMP% ignoriert wird.

Nur warum wird beim Ansprechen des PDFCretors über COM das Spoolverzeichnis dann passend zur %TEMP% Variable angelegt? Also unter ..\\AppData\\Local\\Temp\\2\\PDFCreator.

Die 2 steht stellvertretent für eine beliebige Sitzungsnummer.

Unter Windows 2003 mit dem PDFCreator 0.9.3 funktioniert das ganze mit PrinterTemppath jedenfalls problemlos.

 

Christian

 

5

Hallo Christian,

ich konnte die Problematik hier nachstellen. Das Problem liegt daran wie der Temp-Pfad in einer Terminalserverumgebung ermittelt wird. Die Monitor-DLL erzeugt mit Hilfe der API CreateEnvironmentBlock die Umgebung für den PDFCreator. Durch diese Funktion wird der TEMP-Pfad des Benutzers auf
"C:\\Users\\\\AppData\\Local\\Temp\\"
gesetzt. Durch den Anmeldeprozess eines Benutzers ändert Microsoft diesen jedoch in der Umgebung auf
"C:\\Users\\\\AppData\\Local\\Temp\\\\".
Startest Du per COM den PDFCreator wird er in der Umgebung des angemeldeten Benutzers gestartet. Er verwendet also "C:\\Users\\\\AppData\\Local\\Temp\\\\". Wird der PDFCreator vom Druckprozess aus gestartet, schaut er auf "C:\\Users\\\\AppData\\Local\\Temp\\".

Die Variable "PrinterTemppath" wird nicht mehr verwendet. Sie kann unter Umständen zu Irritationen führen. Es gab Benutzer die legten diesen Pfad auf die "Eigenen Dateien" und mit dem COM-Befehl ClearCache kann der Inhalt des Pfades komplett gelöscht werden.

Wir werden im Team besprechen, welche Möglichkeiten es gibt dieses Problem zu lösen. Vor Ostern wird das aber leider nichts mehr.

Mit freundlichen Grüßen,

 

6

Hallo Frank,

Danke für die Info, somit kann ich dem Kunden gegenüber zeigen,

dass das Problem nicht bei mir liegt. Das hilft mir schon mal enorm.

Was mich jetzt aber irritiert ist das folgende:

Warum ermittelt die Monitor.dll den Temppfad ohne die bei Verwendung von COM wird aber der richtige Temppfad verwendet? Der Start der Monitor.dll muss doch auch schon in der Benutzerumgebung erfolgen. Ermittelt die Monitor.dll den Pafd evtl. nur anhand des mit vordefinierten restlichem Pfad?

Schöne Ostern!

Gruß Christian

7

Hallo Frank,

mir ist da gerade eine Idee gekommen, besteht die Möglichkeit bei der Ermittlung des Temppfades durch die Monitor.dll die SessionID des Anwenders abzufragen und an den vorher ermittelten Pafd anzuhängen ?

Gruß Christian

8
<!–[if gte mso 10]> /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Normale Tabelle"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin-top:0cm; mso-para-margin-right:0cm; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0cm; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:EN-US;}

<![endif]–>

Hallo Christian,

ganz so einfach ist die Sache leider nicht. Selbst wenn die Monitor-DLL einfach die SessionID dranhängt, bleibt die Temp-Umgebungsvariable unvollständig. Es gibt Api-Funktionen die den Temp-Pfad ermitteln und vom PDFCreator genutzt werden. So ermittelt der PDFCreator selbst den Temp-Pfad unvollständig und müsste die Sitzung dranbasteln. Anwendungen die von dem Feature "Aktion nach dem Speichern" gestartet würden, nutzen vielleicht auch diese Api-Funktion und würden so den unvollständigen Pfad ermitteln. Dann gibt es Probleme unter Windows Vista und größer. Hier laufen die alle Benutzersitzungen bereits in einer Sitzung > 0, der Temp-Pfad enthält aber keine SessionID. Dazu kommt, wie funktioniert das mit der schnellen Benutzerumschaltung unter Windows XP (XP, Vista, Win7 sind sogenannte Single-Terminalserver)?? usw. usw…

Vielleicht könnten wir etwas basteln was Dir in deinem spez. Fall helfen könnte, aber es wäre eine Bastellösung. Wir wollen erst mal verstehen warum das so ist. Vielleicht finden wir eine allgemeine Lösung (wenn es die gibt).

Frank

9

Hallo Frank,

mir würde es vermutlich schon helfen, wenn PrinterTemppath wieder aktiviert würde, denn dann wäre ich von den programmermittelten  Temp Pfaden unabhängig. Entweder könnte ich dann wieder mit %TEMP% arbeiten oder den Eintrag durch das Logonscript ermitteln und setzen lassen.

Drücke die Daumen, dass Ihr eine für alle passende Lösung findet.

BIn beim Kunden jetzt extra von FreePDF auf PDFCreator umgestiegen, weil der unter W2K8R2 einfach besser läuft.

Habe mir das ganze übrigens mal unter W2K3 TS angesehen, allerdinsg noch mit der Version 0.9.3. Da werden die SessionIDs zwar auch ignoriert, aber der Druck über COM läuft dort problemlos.

Schöne Ostern ans ganze Team !

Gruß Christian

10

Hallo Frank,

ich habe mir in meiner Testumgebung einmal die Version 1.2.3 installiert. Diese zeigt bei einer Defaultinstallation mit PrinterTempPath=PDFCreator das gleiche Verhalten. Stze ich aber PrinterTempPath=%TEMP%\\PDFCreator, dann werden die Spoolfiles in allen Fällen unterhalb des SessionID-Verzeichnisses abgelegt.

Die einfachste Möglichkeit sollte es dann doch sein, wenn Ihr in der neuen Version entweder PrinterTempPath wieder zulasst, oder den Pfad auf %TEMP%\\PDFCreator festzurrt.

Die Variable %TEMP% gibt es schließlich in jedem OS und sie kommt vpm System und muss nicht über andere DLLs ausgelesen bzw. ermittelt werden.

Hoffe auf eine baldige neue Version.

Gruß Cranger 

11

Hallo Frank,

habe eben in einem anderen Thread gelesen, dass PDFCreator 1.4 vor der Tür steht.

Ist dort das Problem mit dem PrinterTempPath gefixt ?

Gruß Christian

12

Hi,

 

das Problem mit der SessionID ist gelöst.

 

MfG

 

Robin

 

13

Hi Robin,

das ist schön zu hören. Dann kann mein Kunde das ganze endlich einsetzen, ohne sein Programm umbauen zu müssen.

Ist die Variable PrinterTempPath immer noch deaktiviert,oder habt Ihr sie zur Problemlösung  wieder aktiviert ?

Gruß Cranger

14

Nein, die Variable PrinterTempPath wird nicht mehr verwendet. Es git auch keinen Plan diese wieder einzuführen, aber jetzt müsste das Problem behoben sein.

Beste Grüße,

15

Hallo Frank,

habe mir jetzt in meiner Testumgebung mal den PDFCreator 1.4.0 installiert um das Verhalten zu beobachten. Es werden nun zwei Spoolverzeichnisse erstellt, einmal direkt unter..\\Temp\\PDFCreator\\Spool und einmal unter der SessionID. ..\\Temp\\\\pDFCretor\\Spool.

Da ich in der Testumgebung keinen Zugriff auf das Programm vom Kunden habe habe ich es mit den COM Samples probiert.

Folgendes ist mir dabei aufgefallen:

Schiebe ich per Drag&Drop eine TextDatei auf das Sample Convert2PDF, dann werden im Ordner \\Temp\\PDFCreator\\Spool zwar die PS Dateien ertsellt, es geht aber nicht weiter.

Öffnet man den PDFMonitor manuell, dann wird die PS Datei nicht angezeigt.

Erst wenn ich über einen normalen Druckvorgang eine neues PDF erstelle, und sich der PDFMonitor öffnet, erscheint der erste Sample Ausdruck ebenfalls im Monitor.

Automatisch kommt da leider nichts raus.

Gruß Cranger

16

Hallo Christian,

 

es wäre super, wenn Du einmal das neue Logging für die pdfcmon.dll aktivieren und uns das log schicken könntest. Dazu muss ein neuer Registry Eintrag in HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Print\\Monitors\\pdfcmon mit Name : Logging, Wert : 1 (als 32 bit DWORD) erstellt werden, das log wird dann in %Windir%\\Temp\\_pdfcmonLog.txt gespeichert. Damit würdest Du uns einen großen Gefallen erweisen:)

 

MfG

 

Robin

17

Ich wollte euch auch einmal eine Rückmeldung geben, da ich das Programm mittels COM Schnittstelle verwende und SEHR gut finde.

Ich hatte auch die Problematik mit dem Spool-Verzeichnis (und habe es auch immer noch - aber durch einen Workaround gelöst).

Version ist die 1.4.0, BS ist Windows XP. Der Druckertreiber hat korrekt die .ps Dateien im Spool-Temp erzeugt. Aber PDFCreator wurde nicht aktiviert. Mehrfaches Booten / neu installeiren und Löschen von temporären Verzeichnissen hat nichts bewirkt. Mit der Hilfe dieses Threads habe ich mir das dann im Detail angeschaut und das Ergebnis ist:

Der Druckertreiber schreibt die Dateien nach: %USERDIR%\\Lokale Einstellungen\\Temp\\1\\PDFCreator\\Spool

Und PDFCreator wartet in %ÙSERDIR%\\Lokale Einstellungen\\Temp\\PDFCreator\\Spool auf ankommende Dateien.

Transferiere ich die Dateien händisch in den korrekten Ordner läuft es alles einwandfrei. Warum das hier unter Windows XP so ist - ich weiß es nicht (es läuft noch eine zweite Instanz auf einem Windows Server 2003 - dort war es kein Problem...)

Die Pfade kann ich nicht beeinflussen....also habe ich aktuell folgenden Kunstgriff verwendet:

mklink installiert und mit /J (Junction) einfach den Inhalt von \\1\\Spool auf den richtigen Ordner gespiegelt - FUNKTIONIERT.

Ich hoffe es bringt euch hier für die nächsten Versionen weiter...ihr solltet mal ergründen, warum der Druckertreiber dieses \\1\\ einbaut.


Grüße

LHRookie

 

18

Hallo LHRookie,

die \\1\\ ist Deine SessionID und wird seit Windows 7 bzw. Windows 2008R2 verwendet. Die SessionID wird vom System vergeben. Da du unter Window 7 ja auch den benutzerwechseln kannst bzw. auf W2K8R2 als Terminalserver ja zig User haben kannst, wird dein Trick mit dem festen Umleiten des Verzeichnisses dann nicht funktionieren, da Du in beiden Fällen Deine SessionID im Normalfall vorher nicht wissen kannst. Mit der nächsten version wird das Problem aber wohl gefixed sein.

Gruß Cranger