Printing multiple copies on remote printers

[Helge Blischke]

I think there is an issue with the handling of the copies attribute in
general.
The pstops filter sets the /NumCopies value in the page device
dictionary
(for language level >= 2; the /#copies value otherwise), but some
backends
on the other hand set the copies attribute in addition, e.g. the IPP and
the LPD
backend.
As the IPP RFCs don't specify which specification takes precedence, it
is implementation
dependent what really happens.

Helge


Anonymous wrote:
> 
> I am seeing similiar issues with local queues.  It appears that the jobs get queued multiple time.  It is generating multiple job ids for only 1 requests.  I end up getting anywhere from 2 to 10 copies of the same request.  I am seeing this both on Solaris 9 with cups 1.1.19 and the RHEL 3.0 version 1.1.17-13.3.22.
> 
> Is anyone else seeing this?
> Is it a problem with cupsd or lp or both?
> What information do you want to help debug this?
> 
> > russell-cups at stuart.id.au wrote:
> > > This bug has been observed in cups-1.1.20final+rc1 that
> > > comes with Debian, and cups-1.1.22 compiled from source.
> > >
> > > Remote printers are occassionally printing multiple
> > > copies of jobs.  None of the jobs had the "copies"
> > > option set.
> > >
> > > The multiple copies was caused by two things:
> > >
> > > 1.  Made http_wait() did not handle EINTR.
> >
> > This is an issue, but your fix is not the correct implementation
> > since it only handles a single interruption.
> >
> > > 2.  The wait in ipp_http_read was too short for connections
> > >     that run over the internet.
> >
> > Setting a 2 minute wait here is not appropriate; http_wait() is
> > only used when reading fragments in non-blocking mode, and only
> > the scheduler uses this mode.  Putting a 2-minute wait in the
> > scheduler opens CUPS up to additional DoS attacks but will not
> > resolve the problems you are seeing.
> >
> > > Note:
> > >     While both these bugs need to be fixed, neither completely
> > >     solves the original multiple copies problem.  To solve
> > >     that no data should be printed if there was a read or
> > >     other error.
> >
> > The usual response to HTTP or IPP errors in the initial query
> > phase of the backend's job submission is to retry the request or
> > connection.
> >
> > As we have never seen this particular problem before, I would
> > appreciate tcpdump/ethereal packet dumps of the traffic between
> > client and server so that we can determine at what point the
> > transaction is failing.
> >
> > Thanks!
> >
> > PS - you can post this problem and the dump files using the STR
> > form at:
> >
> >      http://www.cups.org/str.php
> >

-- 
Helge Blischke
Softwareentwicklung
SRZ Berlin | Firmengruppe besscom
http://www.srz.de