Commits failed for me when using a cvs built from cvs-1.11-2.src.rpm. The problem was that the last security patch added an extra unlink(), but it didn't check if the error was ENOENT before failing. The ENOENT should be fine in this case. Please see below for a patch. I also changed the sense of another existence_error() test that seemed obviously wrong from my eyeballing the code. I didn't test that change, however. ---------------------- --- cvs-1.11/src/rcs.c.unlink Sun Jan 28 23:27:24 2001 +++ cvs-1.11/src/rcs.c Sun Jan 28 23:58:02 2001 @@ -4317,7 +4317,7 @@ /* Unlink `dest', just in case. It's okay if this provokes a ENOENT error. */ - if (unlink (dest) < 0 && existence_error (errno)) + if (unlink (dest) < 0 && !existence_error (errno)) error (1, errno, "cannot remove %s", dest); if (mknod (dest, special_file, devnum) < 0) error (1, errno, "could not create special file %s", @@ -4340,7 +4340,7 @@ { /* Unconditionally remove the old file, so that safe_fopen * can succeed */ - if (unlink_file (sout) < 0) + if (unlink_file (sout) < 0 && !existence_error (errno)) error (1, errno, "cannot remove %s", sout); ofp = CVS_SAFE_FOPEN (sout, expand == KFLAG_B ? "wb" : "w"); if (ofp == NULL)
This should be fixed in cvs-1.11-3. (The first instance even conflicts with the comment which precedes it, so I'm pretty sure you're correct about it being wrong.)
*** Bug 25995 has been marked as a duplicate of this bug. ***
*** Bug 26994 has been marked as a duplicate of this bug. ***
*** Bug 27447 has been marked as a duplicate of this bug. ***
*** Bug 34872 has been marked as a duplicate of this bug. ***