Bug 35636 - lpr lpr_bounce support broken, data file transfername set to <NULL>
Summary: lpr lpr_bounce support broken, data file transfername set to <NULL>
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: LPRng (Show other bugs)
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-04-11 14:38 UTC by Mitch Sukalski
Modified: 2007-04-18 16:32 UTC (History)
2 users (show)

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: ---


Attachments (Terms of Use)
fix that saves old transfername in data file line_list for print job after filtering (1.58 KB, patch)
2001-04-11 14:42 UTC, Mitch Sukalski
no flags Details | Diff

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.



Note You need to log in before you can comment on or make changes to this bug.