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.
> From: cvsnt-bounces at cvsnt.org > [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of news.cvsnt.org > Sent: Monday, 04 December, 2006 15:50 > To: cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook > Subject: Re: [cvsnt] CVS reported error: cannot rename file > (Not AV problem) > > > On windows this is handled by the Windows API MoveFile() to > ensure that it happens as quickly and efficiently as possible. Unfortunately, in this case, "as possible" is neither very quick nor very efficient. In fact, it's not atomic, and it's known to suffer from race conditions. See for example this Usenet thread: http://groups.google.com/group/microsoft.public.win32.programmer.kernel/ browse_frm/thread/74480e5ebb7ace60/f19b457c1334676f The Win32 API just isn't very good at file metadata operations. (Apparently there's an article in "NT Insider", an online newsletter published by OSR Online, which describes how MoveFile / MoveFileEx work in some detail, but you have to subscribe to read it. Try www.osronline.com if you're interested.) > If that is failing then it > is a very low level error - most likely something wrong with the disk > driver, or something like AntiVirus which sits in the IFS > stack and can "interrupt" calls between the Win32 API and the driver > level APIs. Alas, people have reported this problem with various services that perform many file rename operations under Win32, even with stripped-down systems. Some issues were apparently fixed with XP SP2 (so the OP should put SP2 on, if it's not already); others can be avoided by disabling background disk operations like the defragmenter and the indexing service (which really should not be running on a disk used for CVS anyway).