> 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]