-----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:[EMAIL PROTECTED]> -----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----- _______________________________________________ Bug-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-cvs
