Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 35636

Summary: lpr lpr_bounce support broken, data file transfername set to <NULL>
Product: [Retired] Red Hat Linux Reporter: Mitch Sukalski <mitch>
Component: LPRngAssignee: Tim Waugh <twaugh>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1CC: crutcher, drector
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-01-21 12:43:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
fix that saves old transfername in data file line_list for print job after filtering none

Description Mitch Sukalski 2001-04-11 14:38:02 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.1-0.1.9 i686)


If lpr_bounce support is used to pre-filter a print job before sending the
job to a remote printer, then the data file transfer name is mistakenly set
to <NULL> instead of the proper dfXXXXhost name.

Reproducible: Always
Steps to Reproduce:
1. set up a printcap.local entry to use lpr_bounce, a local filter, and a
remote printer
2. try to print a file to it using lpr
3. no error will be reported, but not output will be produced (an lpr -V or
lpr -D5 will
show that the data file "<NULL>" has been sent to the remote printer)
	

Actual Results:  No error will be reported (exit status 0), but no output
will ever be printed

This is a bug with lpr distributed with LPRng version 3.7.4
Comment 1 Mitch Sukalski 2001-04-11 14:42:10 UTC 
Created attachment 15164 [details]
fix that saves old transfername in data file line_list for print job after filtering
Comment 2 Crutcher Dunnavant 2001-04-18 15:57:07 UTC 
I will look at this some more, but I dont fully understand the 'correct,
behaviour on this one. There are some permission issues.
Comment 3 Tim Waugh 2001-12-19 12:42:19 UTC 
Crutcher, what are the permission issues that you were thinking of?

Mitch, the line:
  if (old_transfername) free(old_transfername); old_transfername = 0;
looks like it should instead be:
  if (old_transfername) { free(old_transfername); old_transfername = 0; }

Do you agree?
Comment 4 Mitch Sukalski 2001-12-19 16:41:46 UTC 
You are correct that the if statement scope should include both the free() and old_transfername = 0 statements...sorry about the slop...
Comment 5 Tim Waugh 2001-12-19 22:52:47 UTC 
Well, it's a moot point anyway.  This is fixed upstream (3.8.3).
Comment 6 Tim Waugh 2002-01-10 13:43:17 UTC 
See also bug #20115, which may or may not be related.
Comment 7 Tim Waugh 2002-01-22 13:53:58 UTC 
Fixed in LPRng-3.8.4-1.