Print Job Removal In CVS Version, minor note

[papowell at astart.com]

I was testing the 'job removal' and it was failing.

I was baffled as the UNIX system reported that it was working
correctly,  the job was removed.  I looked at the code in the
CVS release:
> 
> /****************************************************************************
> delete a print job
> ****************************************************************************/
> BOOL print_job_delete(struct current_user *user, int jobid)
> {
>     int snum = print_job_snum(jobid);
>     BOOL owner;
>     if (!user) return False;
>     owner = is_owner(user->uid, jobid);
>     /* Check access against security descriptor or whether the user owns their job. */
>     if (!owner &&
>         !print_access_check(user, snum, PRINTER_ACE_MANAGE_DOCUMENTS)) {
>         DEBUG(3, ("delete denied by security descriptor\n"));
>         return False;
>     }
>     if (!print_job_delete1(jobid)) return False;
>     /* force update the database and say the delete failed if the job still exists */
>     print_queue_update(snum);
      ^^^^ AHH!!!
>     return !print_job_exists(jobid);
> }
> 

There is a problem here of the disconnect between the time that the
job removal is 'posted' on the LPD server, the time that the status
is updated, and the time that LPQ will actually get the status.
This is a small race conditition,  and will usually not be visible
unless you have a system with a VERY long printqueue.

You may also get an error message such as 'removed' for the job in
the status queue.  This is CORRECT as the bodies of dead jobs can
be told to 'linger' in the status queue.  This is implemented by
setting the status of the job to 'removed' but not actually removing
the job.

This facility is provided so that system administrators can determine
what happened to users jobs when they claim 'but it just disappeared!'
and whinge for more print pages.  (Whinging is a cross between
whining and Shakespearean Drama, practiced at all Help Desks at
Academic Institutions,  but most often seen at EE/CS Labs.)

Perhaps just forgetting about the 'success/failure' action and
always assuming success?


Patrick Powell                 Astart Technologies,
papowell at astart.com            9475 Chesapeake Drive, Suite D,
Network and System             San Diego, CA 92123
  Consulting                   858-874-6543 FAX 858-279-8424 
LPRng - Print Spooler (http://www.astart.com)