hazards of linking directories

[Guy Harris]

> But, more seriously: a line printer spooler that "spools" by
> LINKING the print file into the spool directory??? What if you
> make changes in the file between the queue time and the time it
> is actually printed? When I say "lpr foo" I assume that "foo" is
> conceptually being printed RIGHT NOW, and that the spooling
> mechanism exists only to make efficient use of a resource (the
> printer). I'd feel free to modify the file, secure in the
> knowledge that it would be printed in its original form.
> 
> Is this the standard System V printer spooler that does this?
> I understand the problem if you are running XENIX with floppy
> disks, but hopefully a REAL system spooler would never do this...

The spooler that comes with V7 and System III does this linking; it's
sort of a halfassed idea, considering it only works for files on the
same filesystem as the spool directory.

Most of the time when I'm printing something, it's the output of a program
so "lpr" had to read its standard input pipe and squirrel away a copy of
the file anyway.  Since the UNIX spooler doesn't do any pagination (which
it shouldn't do), I always use "pr" when printing files, so the original
copy isn't what's being printed.  If it's a document, either it's coming
from "nroff" or it's coming from our office automation system; in either
case it's a piped copy getting squirreled away.

Sometimes, you're printing such a huge job that it won't fit on /usr/spool,
in which case a strategy like storing the name of the file in the queue,
or making a symbolic link, is the only way to print the job (short of
seizing the printer and doing "cat file >/dev/lp").

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy