Re: Two head revisions?

[Todd Denniston]

Derek R. Price wrote:
> Todd Denniston wrote:
>
>
> > Backup just a second here...
> > Are you telling us you have a way to get CVS to create the corruption?
> > Got a script to do it? Mind sharing?
>
>
> I can recreate the original corruption I described, but it requires a
> corrupted archive to start with.  It is extremely easy to create the
> original corrupted archive - just commit a few revisions to a file (say
> 4, for point of example), then delete the metadata but not the change
> text for the most recent (in the example, 1.4) and edit the "head" tag
> in the archive header to point to the earlier revision (in this case,
> 1.3).  I plan to produce a patch to detect this sort of corruption
> instead of silently further corrupting the file, but it still doesn't
> explain the original corruption.
>
> Anyhow, I've attached a script to demonstrate. It demonstrates the
> problem with top-of-tree on both stable and feature.  If you have any
> ideas where the original corruption may have come from (confirmed by
> retrieval from tape backup), please enlighten me.
>
> Regards,
>
> Derek

What I think I know:
CVS makes a ,file,v to lock and write the new data in.
If CVS is killed/dies hard the ,file,v can be left around.

Something to think about:
What order does CVS/RCS re/write the ,file,v?
	does it by chance write the deltas and head text then come back and mod the 
"head	version;" and then the metadata?

IFF CVS rewrites in sections then it might have been possible for it to be 
killed and then an well meaning admin to have moved the ,file,v to file,v. I 
know reaching for straws.

or even someone not wanting their 1.4 around anymore, vi'ing the file but not 
getting finished?

Flaky mmap implementation? Remember my problems with a solaris 2.6 mmap 
implementation.

--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter