----- Original Message -----
> Hi Phil,
>
> On Mo 11 Apr 2011 13:25:55 CEST "--[ UxBoD ]--" wrote:
>
> > ----- Original Message -----
> >> Hi Phil,
> >>
> >> On Mo 11 Apr 2011 12:07:57 CEST "--[ UxBoD ]--" wrote:
> >>
> >> > 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.
> >>
> >> is that x2goclient or PyHoca-GUI/Python X2go? With PyHoca-GUI this
> >> should not happen, otherwise it is a bug I have missed so far...
> >>
> >> Greets,
> >> Mike
> >>
> >>
> >>
> >
> > x2goclient 3.01.18.
>
> we have an unofficial bugtracker that we (the devs and the community)
> still have to discuss about. However, maybe you place such stuff in
> there already. In case of dropping the software again (Horde) we will
> surely migrate the already placed-in tickets.
>
> The chance of forgetting such tiny issues without accounting is
> otherwise potentially given...
>
> Greets,
> Mike
>
Mike,
I think I may have worked out why some print jobs are failing and it would appear to be an x2go issue and not SSHFS/WAN.
What is happening is that the Perl script, x2goprint, moves the PDF from /var/spool/x2goprint into the users mounted spool directory and then creates the .ready file. The x2goclient looks for any new files in that directory and if it sees the .ready file it pops up the x2go print dialogue window. Now, looking at the code it appears to remove the file as-well; in 3.01-18 the pertinent code is in onmainwindow_part4.cpp line 200.
I am thinking this is a timing issue with respect to the .ready file being written and the slot which monitors the local spool directory firing off an event.
Just not sure how to solve it yet :(
--
Thanks, Phil