Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 35636 - lpr lpr_bounce support broken, data file transfername set to <NULL>
lpr lpr_bounce support broken, data file transfername set to <NULL>
Product: Red Hat Linux
Classification: Retired
Component: LPRng (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-04-11 10:38 EDT by Mitch Sukalski
Modified: 2007-04-18 12:32 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-01-21 07:43:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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 10:42 EDT, Mitch Sukalski
no flags Details | Diff

  None (edit)
Description Mitch Sukalski 2001-04-11 10:38:02 EDT
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 10:42:10 EDT
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 11:57:07 EDT
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 07:42:19 EST
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 11:41:46 EST
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 17:52:47 EST
Well, it's a moot point anyway.  This is fixed upstream (3.8.3).
Comment 6 Tim Waugh 2002-01-10 08:43:17 EST
See also bug #20115, which may or may not be related.
Comment 7 Tim Waugh 2002-01-22 08:53:58 EST
Fixed in LPRng-3.8.4-1.

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