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