SMITH, Gregory C.
2005-Apr-08 21:42 UTC
[Samba] Cups print jobnames became SMB jobname not doc name
Since upgrading to Fedora Core 3 the jobname for the files being printed to our PDF CUPS backend have become the Samba jobname as in "SMBPRN.888009.hjdcl" instead of the application filename such as "Microsoft Word - Document1.DOC". This stops us from providing a properly-named PDF file to our users. Our other server that is still on Core 1 does not have this problem. I've seen other mentions of this problem going back several years but no definitive answer. Can anyone advise what action to take? Thanks, Greg
Gerald (Jerry) Carter
2005-Apr-10 05:05 UTC
[Samba] Cups print jobnames became SMB jobname not doc name
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 SMITH, Gregory C. wrote: | Since upgrading to Fedora Core 3 the jobname for the | files being printed to our PDF CUPS backend have | become the Samba jobname as in "SMBPRN.888009.hjdcl" | instead of the application filename such as "Microsoft | Word - Document1.DOC". This stops us from providing | a properly-named PDF file to our users. | | Our other server that is still on Core 1 does not have | this problem. I've seen other mentions of this problem | going back several years but no definitive answer. This is currently by design and I've not come up with a better solution yet. The problem is the API used to map SMB job id's to unix job id's. The API was originally designed around lpd/BSD printing and so CUPS is dound by that current limitation. If anyone has a clean way to solve this, I'm open to ideas. But changing the API is not a practical option at this point. cheers, jerry ====================================================================Alleviating the pain of Windows(tm) ------- http://www.samba.org GnuPG Key ----- http://www.plainjoe.org/gpg_public.asc "I never saved anything for the swim back." Ethan Hawk in Gattaca -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCWHe/IR7qMdg1EfYRAvpdAJ9yTTdnt7giynkfBhV+Qo/FX2Em5gCdEDSu TY4pElRfF8snZJ/pncppZkg=m/Uq -----END PGP SIGNATURE-----
SMITH, Gregory C.
2005-Apr-10 06:51 UTC
[Samba] Cups print jobnames became SMB jobname not doc name
Hi Jerry, Is this something that changed in a recent version of CUPS? The server that works (Fedora Vore 1) has: cups-1.1.19-13 samba-3.0.7-2.FC1 The server that doesn't (Fedora Core 3) has: cups-1.1.22-0.rc1.8.5 samba-3.0.11-1 Greg -----Original Message----- From: Gerald (Jerry) Carter [mailto:jerry@samba.org] Sent: Saturday, April 09, 2005 5:48 PM To: SMITH, Gregory C. Cc: 'samba@lists.samba.org' Subject: Re: [Samba] Cups print jobnames became SMB jobname not doc name -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 SMITH, Gregory C. wrote: | Since upgrading to Fedora Core 3 the jobname for the files being | printed to our PDF CUPS backend have become the Samba jobname as in | "SMBPRN.888009.hjdcl" | instead of the application filename such as "Microsoft Word - | Document1.DOC". This stops us from providing a properly-named PDF | file to our users. | | Our other server that is still on Core 1 does not have this problem. | I've seen other mentions of this problem going back several years but | no definitive answer. This is currently by design and I've not come up with a better solution yet. The problem is the API used to map SMB job id's to unix job id's. The API was originally designed around lpd/BSD printing and so CUPS is dound by that current limitation. If anyone has a clean way to solve this, I'm open to ideas. But changing the API is not a practical option at this point. cheers, jerry ====================================================================Alleviating the pain of Windows(tm) ------- http://www.samba.org GnuPG Key ----- http://www.plainjoe.org/gpg_public.asc "I never saved anything for the swim back." Ethan Hawk in Gattaca -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCWHe/IR7qMdg1EfYRAvpdAJ9yTTdnt7giynkfBhV+Qo/FX2Em5gCdEDSu TY4pElRfF8snZJ/pncppZkg=m/Uq -----END PGP SIGNATURE-----