[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Problem with tempfiles

From: Andy Levy <andy.levy_at_gmail.com>
Date: Thu, 22 May 2008 08:15:27 -0400

On Thu, May 22, 2008 at 3:08 AM, Jens T Thielemann <jenstt_at_gmail.com> wrote:
> Hi!
> I have a problem with Subversion in that its atomic updates of files
> conflicts with my virus killer (this is exactly the same problem as reported
> in http://svn.haxx.se/users/archive-2006-08/0847.shtml). This makes
> subversion usually fail in any action.
> While arguments can be made that this really is a virus killer problem, this
> does not really help me out. As I understand the problem, the virus killer
> will temporarily look at the file, and if Subversion tries to move the file
> simultaneously (due to its mechanism of providing atomic file updates), the
> move will fail. There is thus an element of a race condition here.
> Would it be possible to enhance Subversion to retry such move operations?
> That is, if the first move fails, wait 0.5 seconds and retry? This would
> probably enhance compatibility with virus killer and also indexing software,
> and make the Subversion client much more usable in a viruskilling
> environment.
> Are there any work underway attempting to resolve this issue?

I think SVN already does attempt to retry. The problem is that some
virus scanners hold onto the files longer than that (which is
excessive). The fact that most scanners don't seem to cause issues
should be a strong indicator that the problem is not really with SVN.

Tell your virus scanner to ignore the .svn directories. I understand
that it's a company machine, but company policy should *enable* you to
do your job, not *prevent* you from doing it.

To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-05-22 14:15:49 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.