From: utzoo!decvax!harpo!duke!mcnc!ikonas!mcm Newsgroups: net.unix-wizards Title: lprm bug Article-I.D.: ikonas.128 Posted: Thu Jul 29 14:38:12 1982 Received: Fri Jul 30 04:36:44 1982 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