Hi Phil, On Di 12 Apr 2011 17:11:25 CEST "--[ UxBoD ]--" wrote:
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.
in the pending patch for x2goprint I have changed the mechanism a little. The reason is that we have to presume in general that root cannot read-write to the user's home (e.g. if homes are on NFS3 with root-squashing, NFS4+Krb5, AFS+Krb5 etc.). So what I do is:
o x2goprint scripts runs as root (sudo from x2goprint user)
o copy print jobs to /tmp/spool_<user>/tmp
o chown the files to <user>
o su - to the user and move the print job directly into
/tmp/spool_<user>/<session_id>
... instead of taking the detour via the home dir...
http://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=16cdb70f5bbd129816bcebd4eb3a87a4b7ff71d7
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.
With PyHoca-GUI I have this strategy:
o one printqueue thread is waiting for print jobs
o if a job appears another thread is started that handles the print action
(pdfview, pdfsave, print, ...)
o the print action immediately creates a ,,local'' copy of the print job (to
make sure it does not vanish while processing it)
o whilst the first thread is counting till 60(secs) and then deletes the
original set of job files
o the print actions however have different ways of handling their
local copy:
o on Windows after having processed the print action task (e.g. opening a
pdfviewer) there is a funtion that keeps checking if the file can
be deleted. While it is locked by the file system, it will continue
the deletion attempts till one of them is successful
o on Linux I delete the files directly after I am sure that the job is
processed (e.g. waiting long enough, testing for a print result, ...)
I guess that the creation of a local copy of a print job might be a
solution...
Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419 GnuPG Key ID 0xB588399B mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
pgptKz89d2oJP.pgp
Description: Digitale PGP-Unterschrift
_______________________________________________ X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
