[net.unix-wizards] lprm bug

mcm (07/29/82)

I have also run into the bug in the lprm routine where it truncates
a valuable file to zero length.  Just commenting out the line
	close(creat(file, 0666));
in the drop subroutine takes away most of the effectiveness of the
lprm command.  You can leave some of its effectiveness in if
you check the file name first.  If the file name is in the
spool directory and starts with a 'c', the file was copied
rather than linked into the spool directory.  If it was copied,
there is no reason why you cannot truncate the file.  Included
here is my version of the drop subroutine.

drop(file)
register char *file;
{
	register char *cp;
	char *rindex();

/*
 * truncate the file to zero length only if the file
 * was copied into the spool directory.  A copy is
 * designated by a 'c' as the first character in the
 * file name
 */
	cp = rindex(file, '/');
	if (cp == NULL)
		cp = file;
	else
		cp++;
	if (*cp == 'c')
		close(creat(file, 0666));

	unlink(file);
}

I discovered this bug while I was making modifications for a
Printronix printer/plotter.  We wanted to use the printer in
plot mode, but lpf and the line printer driver had to be modified
so that the &%^*#$ thing wouldn't give a top of form every 66 lines.
In my humble opinion, device drivers should not be very smart at all.
The smarts to the line printer ought to be in lpf, not the driver.
Otherwise, what's the point in having lpf?

		Mike Mitchell
		ucbvax!decvax!duke!mcnc!ikonas!mcm

cak@Purdue@sri-unix (08/28/82)

From: Chris Kent <cak at Purdue>
Date: 23 Aug 1982 11:56:24-EST
Our spoolers (lpr, diablo, versatec, job serializer) all work in similar
fashion -- the daemon writes its PID in a file, and signals can be
sent to it by the queue control program to kill a job, stop it,
restart it, etc. This scheme has been in use for at least 3 years here.
Bob Brown is responsible for much of the code; contact him for
availability (rlb@purdue, decvax!pur-ee!purdue!rlb)

Cheers,
chris