[net.news] UUCP local file naming

Lauren Weinstein <lauren@vortex.UUCP> (08/07/83)

Greetings.  As long as UUCP queue filename "collision" risk is
minimized, I don't see the need for significant restrictions on the
filenames that a site uses for the storage of UUCP D. files *locally*.
The names that they send to a remote site, of course, must meet
the "standard" requirements.  Nonetheless, it is true that certain
local naming schemes could increase the risk of collision significantly,
and we can assume Murphy's Law will ensure that a "1 in a million"
collision will occur within three hours of installing new code.

Given this latter consideration, I will agree that my new naming scheme
could possibly cause a local collision problem in some cases.  Since this
code has the potential for being fairly widely used in the near future,
it seems prudent for me to deal with the issue now.  

One solution is to go back to the "older" naming scheme, where all outgoing
files are names with the "local" sitename.  However, as I've stated
before, I consider this to be undesirable since it can make routine
manual queue inspection somewhat painful.  Another possibility is to
combine the previous "solution" with the concept of having
separate subdirectories for each site (some systems currently
use separate subdirs for at least the "high volume" sites on their
system).  However, I do not consider this appropriate except where
very high traffic volumes are being encountered.  Having lots of small
subdirectories can also cause queue inspection to be a hassle,
especially when many sites, with relatively low traffic for each site,
is the pattern of usage.

There is another solution, of course, that sits squarely in the middle,
and it's the path that I'm now going to take (unless someone can point
out a really good reason why I shouldn't...)  There's no good excuse
why incoming D. files cannot be kept separate from outgoing D. files.
Therefore, I am altering my local naming scheme to use the subdirectories:

C.
X.
D.in
D.out

This technique will allow me to use my previously announced local
file naming scheme without any risk of name collision, and with
a minimal change in the overall directory structure.

--Lauren--
{decvax,ihnp4,harpo,allegra,ucbvax!lbl-csam,randvax}!vortex!lauren

silver@csu-cs.UUCP (08/09/83)

In response to --Lauren--'s  observation that manual  maintenance of the
spool  directory is a pain:  I agree!  And not long after getting turned
on to uucp I wrote a  program  called  uuls(1)  which  shows  the  spool
directory  files  classed into  Transactions,  Orphans, and Others.  The
Transaction  files are  further  grouped  by  transaction  (a C.* or X.*
followed by its  associated  D.* files, with missing files noted).  It's
not TOO hard to write  and it's  VERY  useful.  I don't  see why  nobody
wrote it before.

I wish I could post the source, but it's still potentially  proprietary.
Still, if I see some interest  I'll see what I can do...  maybe post the
manual page as a teaser?

Alan Silverstein, Hewlett-Packard Fort Collins Systems Division, Colorado
ucbvax!hplabs!hpfcla!ajs, 303-226-3800 x3053, N 40 31'31" W 105 00'43"

swatt@ittvax.UUCP (Alan S. Watt) (08/11/83)

I am glad awareness of this serious UUCP bug has hit a significant
number of net sites.  I have come up with several possible solutions.

  1)	Use Lauren's naming scheme for the "D." files such that
	when queued in the originating system, they are named

		D.<destination_system><seqno>
	
	but when they arrive at the destination system they
	are renamed

		D.<origin_system><seqno>
	
	As people have noted, this cannot be implemented on
	only a partial set of systems, as it will increase collision
	chances for systems running the original code.  To make
	it work, you would have to use subdirectories, or at least
	one for all "incoming" work.

	The file naming nonsense is spread out in several places in
	"uucp.c" and "uux.c", and perhaps others as well.  I looked
	into this slightly and it was a bit of a mess.  If you don't
	mind just calling "gename" several times, it is easy, but this
	is expensive unless your sequence numbers are cached (UUCP
	hack published long ago).

  2)	Use the "grade" character to differentiate incoming and
	outgoing stuff.  I, and perhaps others, do use this for
	its intended purpose of assigning priorities to work
	in the queues, but this only affects "C." and "X." files;
	its significance for "D." files is unused at present.
	"O" and "I" could be used to differentiate inbound and outbound
	data files.

	Similar comments as above.

  3)	Use "D.<mumble>" for outgoing stuff, and rename it to
	"d.<same_mumble>" when it arrives at the destination system.

	Same comments as above.

The problem with all of these methods is they require everyone to
adopt the same standards.  Hence my preferred (at present) method:

  4)	Create a separate directory in the UUCP spool directory
	for each system with which you connect.  Fix uucico to prefix
	all incoming spool-destined files with this system name.  Fix
	uuxqt to look there for work based on the "S" line in the "X."
	file which specifies origin system.

	You do have to be careful that uucico's idea of the current
	remote system is always correct, but I can't recall finding
	any bugs on this score.

	This can be done on the local system regardless of what the
	rest of the UUCP world does.

	I also feel a bit less queasy about this hack because I have
	already been into the appropriate places of uucico and uuxqt
	and have a clear idea of what to do.  It does add an extra
	step to the process of adding a new system connection however,
	as you have to create the new subdirectory.

I also tend to prefer this approach because I think the subdirectories
should be named for the system, not the arbitrary "C.", "D.", "X." files
and whatever else is leftover from UUCP kludgery.

	- Alan S. Watt
	(decvax!ittvax!swatt)