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

 
 

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

Submitter:  David Taylor <taylor>
Submitted:  Wed 03 Mar 2010 08:38:11 PM UTC
   
 
Category:  Bug Report Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Release: 
Fixed Release:  None Fixed Feature Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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 Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-03-03 taylor Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.14-79a4.
    Corresponding source code