> What is returned when you do an "INDEX filelist"? Are most > of the non-log files the same size i.e., the size of the > welcome file? By this time we've junked the whole file server and started over. But we are not yet certain exactly what killed it. We do know that a couple of days ago one of us PUT either the filelist (after adding a new file name) or the file itself, and Listserv responded by deleting all the internal fileID's it keeps track of files with. So though all our other files were there, it didn't know they were. When anyone requested any file, it would return the only one it seemed to still know, our welcome letter which was holding position 00001. Though there could have been problems with the file list, it does look like several others we have that work. At first the INDEX correctly described files with appropriate lengths, even though it sent the Welcome Letter instead. When we tried PUTing the latest version of the filelist again, to see if it would help, Listserv changed all the file lengths to the same as the Welcome Letter's (and kept returning the Welcome Letter). When we tried PUTing a couple of files, Listserv deleted the Welcome Letter and whatever had held position 00002, and put the new files in their places. Then it started returning the file in position 0003 (which it supposedly didn't know was there) for any OTHER request, though it correctly recognized the ones we had just PUT. All of us claim nothing we did was unusual or likely to have caused this. But rebuilding the whole thing (as we're now doing) is causing a lot of work--especially since we don't really know why it got eaten in the first place. It was suggested that someone PUT a version of the INDEX of the list, rather than one obtained with the GET command. But everyone insists that isn't possible. Or someone said the file list has to have blank lines in specific places, but we don't seem to be able to find out which missing blank line would kill all the files. (And we have examples of working lists with all the apparent flaws we've been able to find.) If anyone can unravel this fish story and let us know what one can do to kill a file server in this fashion (so we don't do it again after the rebuild) we'd much appreciate your insights. Vickie Banks H-NET Technical Assistance [log in to unmask]