Re: file descriptors consumed by printing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 2 Mar 2003, Richard Sharpe wrote: On Mon, 3 Mar 2003, Tim Potter wrote: On Sun, Mar 02, 2003 at 10:10:53PM -0800, Richard Sharpe wrote: This seems like a good way to do it. Does anyone have any objections if I do so? Why do we need it? Just call lp_default_server_announce() and check if the SV_TYPE_PRINTQ_SERVER bit is set. If no print shares are exported then don't call nt_printing_backend_init(). Hmmm, Samba 2.2.x sets SV_TYPE_PRINTQ_SERVER unconditionaly. It's fixed in HEAD. Yeah, well someone forgot their janitorial duties :-) No. I asked Tim not to merge it since it was more of a change than I wanted to chance in 2.2 at the time. cheers, jerry -- Hewlett-Packard- http://www.hp.com SAMBA Team -- http://www.samba.org GnuPG Key http://www.plainjoe.org/gpg_public.asc You can never go home again, Oatman, but I guess you can shop there. --John Cusack - Grosse Point Blank (1997) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQE+ZLE6IR7qMdg1EfYRApvPAKCgk72wlxQVo80Vq4PYnF6RsfSUDwCg0QbE TQRIxoOSBMzvXGHLFCQcdIE= =3a+F -END PGP SIGNATURE-
Re: file descriptors consumed by printing
On Sun, Mar 02, 2003 at 10:25:27PM -0800, Richard Sharpe wrote: This seems like a good way to do it. Does anyone have any objections if I do so? Why do we need it? Just call lp_default_server_announce() and check if the SV_TYPE_PRINTQ_SERVER bit is set. If no print shares are exported then don't call nt_printing_backend_init(). Hmmm, Samba 2.2.x sets SV_TYPE_PRINTQ_SERVER unconditionaly. It's fixed in HEAD. Yeah, well someone forgot their janitorial duties :-) There's an interesting story about that. (-: At the time I fixed this problem we were in don't touch the 2.2 branch unless it is a critical bug fix, and also in this will be the last version of 2.2 for sure mode. I guess we are still in both those conditions again at the moment! Here's the original problem report: http://lists.samba.org/pipermail/samba-technical/2002-May/036866.html Tim.
Re: file descriptors consumed by printing
On Tue, Mar 04, 2003 at 12:46:28PM +1100, Tim Potter wrote: There's an interesting story about that. (-: At the time I fixed this problem we were in don't touch the 2.2 branch unless it is a critical bug fix, and also in this will be the last version of 2.2 for sure mode. I guess we are still in both those conditions again at the moment! Woo hoo ! Just wait until you see my no-writable strings for 2.2 patch :-). Jeremy.
Re: file descriptors consumed by printing
On Sun, Mar 02, 2003 at 06:54:37AM -0800, Richard Sharpe wrote: On Sat, 1 Mar 2003, Vance Lankhaar wrote: What about adding a value to the printing param? - printing = disabled This seems like a good way to do it. Does anyone have any objections if I do so? Why do we need it? Just call lp_default_server_announce() and check if the SV_TYPE_PRINTQ_SERVER bit is set. If no print shares are exported then don't call nt_printing_backend_init(). I don't think we need yet another parameter when the information is already available. Tim.
Re: file descriptors consumed by printing
On Mon, 3 Mar 2003, Tim Potter wrote: On Sun, Mar 02, 2003 at 06:54:37AM -0800, Richard Sharpe wrote: On Sat, 1 Mar 2003, Vance Lankhaar wrote: What about adding a value to the printing param? - printing = disabled This seems like a good way to do it. Does anyone have any objections if I do so? Why do we need it? Just call lp_default_server_announce() and check if the SV_TYPE_PRINTQ_SERVER bit is set. If no print shares are exported then don't call nt_printing_backend_init(). That seems like a good idea. Seems like you printer-type guys know your way around that code :-) I don't think we need yet another parameter when the information is already available. I agree. Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
Re: file descriptors consumed by printing
On Mon, 3 Mar 2003, Tim Potter wrote: On Sun, Mar 02, 2003 at 06:54:37AM -0800, Richard Sharpe wrote: On Sat, 1 Mar 2003, Vance Lankhaar wrote: What about adding a value to the printing param? - printing = disabled This seems like a good way to do it. Does anyone have any objections if I do so? Why do we need it? Just call lp_default_server_announce() and check if the SV_TYPE_PRINTQ_SERVER bit is set. If no print shares are exported then don't call nt_printing_backend_init(). Hmmm, Samba 2.2.x sets SV_TYPE_PRINTQ_SERVER unconditionaly. I don't think we need yet another parameter when the information is already available. Tim. -- Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
Re: file descriptors consumed by printing
On Sun, Mar 02, 2003 at 10:10:53PM -0800, Richard Sharpe wrote: This seems like a good way to do it. Does anyone have any objections if I do so? Why do we need it? Just call lp_default_server_announce() and check if the SV_TYPE_PRINTQ_SERVER bit is set. If no print shares are exported then don't call nt_printing_backend_init(). Hmmm, Samba 2.2.x sets SV_TYPE_PRINTQ_SERVER unconditionaly. It's fixed in HEAD. Tim.
Re: file descriptors consumed by printing
On Mon, 3 Mar 2003, Tim Potter wrote: On Sun, Mar 02, 2003 at 10:10:53PM -0800, Richard Sharpe wrote: This seems like a good way to do it. Does anyone have any objections if I do so? Why do we need it? Just call lp_default_server_announce() and check if the SV_TYPE_PRINTQ_SERVER bit is set. If no print shares are exported then don't call nt_printing_backend_init(). Hmmm, Samba 2.2.x sets SV_TYPE_PRINTQ_SERVER unconditionaly. It's fixed in HEAD. Yeah, well someone forgot their janitorial duties :-) Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
Re: file descriptors consumed by printing
On Sun, Mar 02, 2003 at 10:25:27PM -0800, Richard Sharpe wrote: On Mon, 3 Mar 2003, Tim Potter wrote: It's fixed in HEAD. Yeah, well someone forgot their janitorial duties :-) I take it that means 3.0 and HEAD will be seeing your cli_XXX 64 bit fixes shortly. :-) :-) :-). Jeremy.
