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