[Info-vax] need help with corrupt MAIL.MAI file

[AEF]

On Nov 24, 8:55 am, Hein RMS van den Heuvel
<heinvandenheu... at gmail.com> wrote:
> On Nov 24, 3:02 am, hel... at astro.multiCLOTHESvax.de (Phillip Helbig---
>
> undress to reply) wrote:
[...]

> So one time reading bucket 27201 it recevieved different results than
> an onther timer.
> That means either a hardware error,  or a shadow set out of sync.
>
[...]

>
> >>  I then RENAMEd the MAIL.MAI to MAI.SAV.
>
> Good. Better than copy.
>
> >> MAIL> SET FILE DISK$USER:[HELBIG.MAIL.MAIL]MAIL.SAV
> >    MAIL> DIR MAIL/START=99999
> > works as expected, as does
> >    MAIL> LAST/EDIT
>
> That's much like the first command working and the second did not.
> It apparently has 2 sources, and you happen to pick the right one
> again.
>
> > What could have caused this problem?
>
> Hardware, or shadowing, or a VBN cache going awry, or Multiple -
> Allocated block style disk corruption?
>
> RMS indexed files is one of the few (only) tools to perform a handful
> of checks before using any data just read. As such they are often
> 'canaries in the coal mine' for underlying problems. Other files may
> just silently return random data.
>
> > Why did the problem go away after I RENAMEd the MAIL.MAI file?
>
> It didn't. It only seemed that way.
>
[...]

> > Possibly relevant information: The disk in question is a 3-member shadow
> > set.
>
> ... a yeah!
>
[...]

> Hein.

Just as an aside, this reminds me of when I did a standalone backup of
a system disk that was a member of a two-member shadow set. I used /
RECORD. Then when bringing the system up with both disks, a DIRECTORY
command would show the backup date oscillating between two values with
each file. So I did a copy operation and all was well. Is there some
better way to have done this?

AEF