Sender: |
|
Subject: |
|
From: |
|
Date: |
Tue, 23 Nov 1993 16:21:06 +0100 |
In-Reply-To: |
Message of Mon,
22 Nov 1993 12:29:00 EST from LISTSERV give-and-take forum
< [log in to unmask]> |
Reply-To: |
|
Parts/Attachments: |
|
|
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
|
|
|