On Mon, 22 Nov 1993  12:29:00 EST "John F. Chandler" <[log in to unmask]>
said:
 
>Consider this scenario: suppose there were a system crash (or maybe just
>a shutdown) while  a message was being processed. The  disk directory is
>not updated immediately when a file has been modified, so it is possible
>to  update a  file and  still end  up  with the  old version  if CMS  is
>interrupted at just the right time.  Is it possible for LISTSERV to lose
>a message from the archive in  this way without losing the corresponding
>entry in the currently accumulating index?
 
Yes, because they are separate files  (and usually on a separate minidisk
as well). I don't remember which file is updated first, but if you have a
system crash one can be updated  and not the other. Alternatively, if you
have a  system crash after  both are updated but  before the CRC  data is
updated,  and the  postmaster releases  the held  file, you  can get  two
copies of  the same  message in  the archive.  These situations  are very
difficult to  handle since  you are appending  to existing  files, rather
than creating  new ones, and  you also indirectly  use a number  of other
files for GLOBALV  data (and LISTSERV's PERMVARS data).  Commands such as
COPYFILE close the files  and expect all files to be  closed on input, or
they will give you an error. About the only solution I can think of is to
copy  all existing  data into  a  new file,  add whatever  you want,  and
ERASE/RENAME everything on completion. Even  so there is the problem that
ERASE updates  the UFD right  away, and that you  can't do a  RENAME with
NOUPDIRT on a SFS  mindisk. You need to add code at  startup to check for
any list  where one  file was  updated but  the other  was waiting  to be
renamed...
 
Anyway I think your problem was just caused by the banner/Date: field.
 
  Eric