bugConcurrent Versions System - Bugs: bug #29058, checksum failure after patch --...

 
 

bug #29058: checksum failure after patch -- user's changes lost

Submitted by:  David Taylor <taylor>
Submitted on:  Wed 03 Mar 2010 08:38:11 PM UTC  
 
Category: Bug ReportSeverity: 3 - Normal
Item Group: NoneStatus: None
Privacy: PublicAssigned to: None
Open/Closed: OpenRelease: 
Fixed Release: NoneFixed Feature Release: None

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Wed 03 Mar 2010 08:38:11 PM UTC, original submission:

Sometimes when doing a ``cvs update'' a user's local changes
to a file will be lost by cvs. You see output like:

cvs update Makefile
P Makefile
cvs update: checksum failure after patch to ./Makefile; will refetch
cvs client: refetching unpatchable files
cvs update: warning: `Makefile' was lost
U Makefile

What has happened is that CVS client thought that the file was
unmodified, so it told the server that it was unmodified. The
server noticed that the file was modified in the repository,
created a patch, and sent it and a checksum. The client applied
the patch and checked the checksum -- which didn't match because
the file IS locally modified. So, it threw away the file and
got an unmodified version from the server.

One way that this can happen is if the user saves the file on
one system and then before the NFS information gets flushed
to disk, issues the cvs update command on a different system.

The client looks, sees old timestamp information that matches
the timestamp in the CVS/Entries file, thinks the file is
unmodified and tells that to the server. When it gets the
patch back from the server, the write that was issued earlier
is now visible on the machine where the commit is occurring
(the file attributes were refreshed by nfs).

What I think that cvs should do is to backup the file before
applying the patch. Then if the checksum fails, the user's
changes aren't lost.

It could then do one of two things:

(1) restore file file from the backup and issue an error
message. The changes aren't lost and a reissued cvs update
will see the new contents and ``do the right thing''. Or,
better:

(2) tell the server that the file IS modified, send the
file contents the way it normally does for modified files,
and proceed accordingly. Only fail if the latter fails.

David Taylor <taylor>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by taylor (Submitted the item)
  • -unavailable- added by taylor
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 03 Mar 2010 08:38:11 PM UTCtaylorCarbon-Copy-=>Added -unavailable-

    Back to the top


    Powered by Savane 3.1-cleanup