Date: Sat, 26 Apr 2008 11:35:12 +0200
From: Spiro Trikaliotis <an-cygwin AT spiro DOT trikaliotis DOT net>
To: cygwin AT cygwin DOT com
Message-ID: <20080426093511.GA9172@trikaliotis.net>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20080419165955 DOT GD11912 AT trikaliotis DOT net> <20080421102419 DOT GA18922 AT trikaliotis DOT net> <045401c8a39b$78a3d3c0$2708a8c0 AT CAM DOT ARTIMI DOT COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <045401c8a39b$78a3d3c0$2708a8c0@CAM.ARTIMI.COM>
User-Agent: Mutt/1.5.13 (2006-08-11)
Subject: Re: Subversion problems with "svn switch", "svn co", "svn switch", because of 'wrong' permissions in .svn/ directories
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Hello Dave,

I am sorry for the late answer, but first, I was on a business trip, and
secondly, I was speaking with the AntiVirus support team to try to find
a fix or, at least, work-around for this issue.

* On Mon, Apr 21, 2008 at 11:35:51AM +0100 Dave Korn wrote:
> Spiro Trikaliotis wrote on 21 April 2008 11:24:
> 
> > Hello,
> > 
> > * On Sat, Apr 19, 2008 at 06:59:56PM +0200 I wrote:
> >> Ok, here is the description: Sometimes (!) when I do a "svn co" or "svn
> >> up", I get the following error: 
> >> 
> >> svn: Can't move 'src/arch/riscos/.svn/tmp/all-wcprops' to
> > 'src/arch/riscos/.svn/all-wcprops': Permission denied
[...]
> > It is a problem of my Anti-Virus solution. So, I have already contacted
> > the company which develops it.

>   Would you mind telling us the name of the AV software at fault, so that we
> can add it to the list?

In my case, it is Antivir Professional (Version 8) by Avira, a German
company (formerly know as H+BEDV). The running process is avgnt.exe, a
registry key path is HKLM\SOFTWARE\Avira\Antivir Workstation\Path which
contains a path to the installed Antivir (in my case,
"C:\Programme\Avira\Antivir Workstation\" - yes, I am using a German
Windows XP, thus, "\Programme\")

Note, however, that this problem did not occur with the former version
7. It seems to be a new feature of the new version 8 which came out on
April 14th. I am still working with the support to find a solution to
this.

They have come up with two work-arounds for the problem:

1. Put SVN.EXE (and CVS.EXE, btw.) into the list of files that are not
   scanned. With this, I do not have any problems anymore. Anyway, I
   consider this to be a big security problem.

or

2. Put the directory where the files are to be checked out into an
   exception list which is not scanned. Again, this work-around works.
   I consider this to be a big security problem too.

Why don't I like these solutions? I regularly check out sources from
different open internet servers (for example, SourceForge). I would like
to get the program checking them out as well as the checked-out
sandboxes under control of the AV program.


There was a third work-around proposal:

3. In Antivir, there is a list of file extensions which are to be
   checked for malware. By default, this list contains the most
   important file extensions (like .exe, .bat, .cmd, .com, and-so-on).
   If I disable this list and tell Antivir to check files on ALL
   extensions, the problem does not completely vanish, but it happens
   much less than before!

Unfortunately, no. 3 has another draw-back: At least for my artificial
test .cmd script I wrote to demonstrate the problem to the Avira
support, the problem has moved.

The script repeatedly performs the following steps:

a. (generate a file test.tmp)
b. copy test.tmp to test.2.tmp
c. move test.2.tmp "over" test.tmp
d. repeat steps b. and c.

Without the work-around #3, the above test does not fail at all. Only
the second variant fails:

m. (generate a file test)
n. copy test to test.2
o. move test.2 "over" test
p. repeat steps n. and o.

Here, step o. fails. You see the difference? In o., the file is named
"test" (w/o extension), in c., it is named test.tmp (w/ extension).


If I use the work-around #3, o. does not fail anymore, but c. does. So,
the problem is moved. Interestingly, though, it does not fail as often
in c. as it did with the original settings, failing in o.

BTW: On my machine, the test m., n., o., p. fails approx. 0.2% of the
tries.

Of course, looking at the script I wrote and the results, it is clear
why SVN and CVS fail mostly on larger check-outs: First, they use this
scheme rather often (for example, CVS generates CVS/Entries.tmp and
moves it over CVS/Entries), but it does not occur that frequently this
it will break always.


I am still trying to convince the AV vendor to accept this as a bug and
fix this issue. IMHO, the scheme "generate a new temporary file and move
it over the original one" is used very often in programs, thus, this
issue might affect many programs. Perhaps, programs like Word for
Windows do not fail on this scheme either because this problem does not
happen that frequently, or because their files all have file extensions.

I will report here if I find a suitable solution.

Regards,
Spiro.

-- 
Spiro R. Trikaliotis                              http://opencbm.sf.net/
http://www.trikaliotis.net/                     http://www.viceteam.org/

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/