Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Miguel, Thanks for the information. Try to send your posts to the newsgroup in 'plain text' if you can - they are much smaller that way. > I read the output using -ttt option, I could not really > get much relevant information; at the end it reads: > > 18:47:48: S -> rcsbuf_fill(010388D0,04B70AB8,0012F3AC,0012F3D8) > 18:47:48: S -> rcsbuf_fill(010388D0,04B71EB8,0012F3AC,0012F3D8) > cvs [server aborted]: unrecognized operation '\x0' in /Path/Sample.bin,v . . . > Type of disk is NTFS. . . . > CVSROOT=:sserver:mhernandez at myserver:/local/cvsroot . . . > File: Sample.bin Status: Up-to-date > > Working revision: 1.486 > Repository revision: 1.486 /Path/Sample.bin,v > Expansion option: b Here are some previous posts on the issue, they don't tell us much: http://www.cvsnt.org/pipermail/cvsnt/2005-August/020791.html And http://www.cvsnt.org/pipermail/cvsnt/2005-January/017070.html Based on the limited information we have this problem indicates an invalid diff in the file (as opposed to a corrupted diff in the file). Now the invalid diff may exist due to a number of reasons including but not limited to: * bad CVSNT (2.0.62.1863) * unsupported use ( deleting -kB revisions) * corruption You do not currently appear to be doing any of the things that usually result in a corrupt repository (using :local:, using NFS/Samba etc). There are several odd things about your installation (including the odd cvsdiag results on the server) but nothing I can directly relate to this problem. Running 'cvs log' on a repository is a way to run a fairly 'simple' test of the integrity of the repository. You have written that running this fails with the "unrecognized operation '\x0'" error. Do you know when this first started appearing? Ie: have you only just noticed that this started occurring or has it only just started occurring? If it is the former (which I suspect it is) then I think the most likely explanation is that someone experimented with -kB revisions, or used :local: or something else to corrupt the revision a long time ago. If it is the latter (which I'd be very surprised about) then we need to find out exactly the sequence of events that led to the RCS file becoming corrupt. The best way to find this is by looking in the audit, though 'cvs history' may tell you a little information if you do not have audit installed/enabled/configured. I look forward to your reply. Regards, Arthur