Eric Thomas <ERIC@FRECP11>
Sat, 9 May 1987 20:33 SET
|
It is now possible to PUT filelists (with release 1.5j). It takes a hell of
a lot of time because LISTSERV must check a lot of things, and then it must
also refresh the filelist to make sure that the date/time fields are correct.
I will perhaps get complaints from several people about this but I prefer to
have something slow that detects problems rather than something faster that
doesn't and consequently causes a few more pieces of mail to land in my reader
:-) And, what the heck, you're not going to store a filelist every 10 minutes,
or if you really must you should be able to find a way out with generic
fileids.
The checks that are being performed are:
1) General syntax checking on the file definition lines and FAC definition
lines.
2) All the FACs must be either hardcoded ones or defined in the header.
3) No new filelist can be created, except by the postmaster. That is, if your
filelist contains a definition for another filelist, and if the previous
version of the filelist did not, then your PUT is rejected (unless you are
a postmaster). This is similar to disallowing the creation of new lists by
Joe users (or even by list owners).
4) Each file must be defined only once.
-- If you remove a file from the filelist, it must have been previously
deleted by means of a LSVPUT (PUT DELETE. Otherwise your PUT is rejected:
the file would remain on the disk but would be defined nowhere in the
filelist and you would not be able to delete it. It would just be wasted
disk space.
It does not check EVERYTHING though. It is probably possible to store an
invalid filelist that would pass the tests but cause funny results. The
checker is here only to detect possible omissions/misspellings -- it is slow
enough and was boring enough to write.
Because of its lack of speed it acts like a compiler and doesn't stop at the
first error. That way you don't have to resend the file three times if there
are three errors, and wait for three times 10 seconds to get the result.
Important notes:
1) You must manually remove the NOTEBOOK section before storing the filelist.
I know that people will forget it half of the time, but I have not yet
found a way to detect the beginning of the NOTEBOOK stuff automatically.
After all you MIGHT want to change the GET/PUT info for some of those files
so I must not disallow the inclusion of NOTEBOOK files in the filelist.
2) My first remark was stupid actually. You must NOT store a filelist which
you have obtained by means of IND or normal GET. You must obtain it by
means of a SENDFILE (SF) command or a GET (CTL command before modifying it.
This file will not contain the NOTEBOOK section.
The file you get with INDEX or normal GET does not contain any FAC
definition nor any password. The file you are going to store must contain
them. LISTSERV doesn't check for that, but with the FAC cross-reference
test I doubt that you would be able to store a filelist that doesn't have
the FAC definition section (unless you use only hardcoded FACs, and in that
case you will only have succeeded in duplicating the hardcoded FACs blurb
section -- no damage to the "important" parts of the filelist).
3) You must not change the order of generic entries below a generic fileid if
you have defined the generic fileid as being sorted (A or D flag). The
entries would not be re-sorted and new files would be inserted in
inappropriate order.
You can change the order without problem if the generic fileid was
configured to append new files on top or bottom (T or B flag). In any case
you must not add or delete lines between the generic fileid line (the one
with the '>' sign) and the end of the file definition lines generated from
that fileid. I don't see any reason why you would want to add a new file
definition right in the middle of a generic fileid list and nowhere else in
the filelist, but I'm getting used to seeing strange things happen
recently, such as receiving BITEARN NODES on LISTSERV's temp disk and then
being surprised that it gets lost -- a severe bug in the code obviously
(no, I'm not kidding, it's a true story! :-) )
Eric
|
|
|