----- Original Message -----

Hi Phil,

On Mo 11 Apr 2011 10:26:16 CEST "--[ UxBoD ]--" wrote:

...

Agreed Mike; though I have the feeling it may be less worth than the effort involved unless somebody knows the internal working of Perl and SSHFS ? A sleep could be added though I have tried to avoid slowing down the process to much. Since adding that loop code we have not experiencing any further failures; though time will tell.

I already had a look at the printing code in x2go some time ago.

There basically are three components:

o cups-x2go o x2goprint o x2goclient

If I recall it corrently the interaction between cups-x2go and x2goprint was not optimal then. I guess it was cups-x2go that left over some print job files whenever a print job was sent to the client, but I am not sure anymore. A person that was not in the x2goprint group also created orphaned print jobs in /, because they were not picked up properly by x2goprint. My observations all were a little odd. Whenever I have time, I will take a look at the mechanism and come up with some patches.

The x2goprint <-> x2goclient communication is rather simple: x2goprint drops two job files in the spool dir: <job>.pdf and <job>.pdf.ready. The X2go client has to run a thread that watches this spool dir (it's in the x2go session cache folder under ~/.x2go/C-.../spooll). On each incoming print job it has to wake up and take over the task of processing the print job. My Python implementation of this printqueue can be found here (if you prefer Python to Perl for a lecture...):

http://code.x2go.org/gitweb?p=python-x2go.git;a=blob;f=x2go/printqueue.py;h=...

Greets, Mike

Yep that is my interpretation of the process as-well, Mike. One thing I have noticed is that if you print the resultant PDF the file is left in the spool directory without being deleted; yet if you cancel from the x2go-print dialogue box the file is removed.

Thanks, Phil