Re: Two head revisions?

[Derek R. Price]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Todd Denniston wrote:
> 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?

CVS write the ,file, linearly, start to finish, there is no seeking
within the file.  It also opens the ,file, O_CREATE | O_EXCL |
O_TRUNC, and has for a long, long time, so it can't be another CVS
process finding an old ,file, and munging it in an attempt to work
with it.

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

Unlikely.

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

It looks superficially like this could have happened.  The sysadmin
responsible for the server assures me that no one with direct write
access to the repo would do this, however.

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

I hadn't remembered, but I pulled the thread up via Google.  I don't
think it would be mmap for several reasons.  The first is that this
server has been running a version of CVS that uses mmap for years
without any other evidence of corruption.  Also, I am at a loss to
explain how a flaky mmap could cascade into this sort of corruption.

I can actually come up with a broken-locks scenario to duplicate this
corruption, but it would require three processes, at least two of
which missed the locks of the third, and the timing is such that it
sounds extremely unlikely:

There is a point where CVS pauses while rewriting a file and reopens
the original to copy the change texts out into the new file.  Thus, my
thinking was that a tag operation, for instance, competing with a
commit without locks, could read the file and write the header, then
reread the change texts out of the new version of the file created by
commit, with extra revisions, and copy those, leaving something like
what got pulled from backup.  Unfortunately, this doesn't work,
completely, since the tag process would have reopened the file at an
index it remembered, just before the original change text, and after a
commit that would be off by 78 characters or so.  That index can only
be about 2 characters off without the reread, and thus the write,
failing.  This scenario could still work if a third process is added,
also competing with the first without locks, which deletes a different
78 characters from the archive header (for instance deleting a really
big tag) just before or after the commit and after the first tag has
read the archive the first time.  Again, all of this happening at just
the right time and in just the right order sounds extremely unlikely
to me.

Regards,

Derek

- --
Derek R. Price
CVS Solutions Architect
Get CVS support at Ximbiot <http://ximbiot.com>!
v: +1 248.835.1260
f: +1 248.835.1263
<mailto:derek@ximbiot.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEWR79LD1OTBfyMaQRAtDdAJ9SFyDnvP3cjbT0R7uNK23bIey6TwCcC9KF
qduxCNUWBOxIq1bxGhPVq+Q=
=V/vW
-----END PGP SIGNATURE-----