Re: Deleting trouble

D.J. Heap wrote:
> Can you post a reproduction recipe?
Yes, summing up my previous postings at the bottom:

> Do you have a realtime virus scanner enabled?
Yes, McAfee VirusScan profesisonal.

> Even with an intrusive AV system this never occurred
> 100% of the time for me, so it sounds like it might be a different
> problem.
It occurs 100% of the time, when the WC contains uncommitted changes.
Maybe that's why nobody noticed it before. When the WC is not modified,
the error doesn't occur.

> The ugly resolution could be the same, of course, but I've
> never seen this aspect of the problem so far.

Try the following recipe under Win2K. You have to have TortoiseSVN
installed.
McAfee's background scan has to be enabled.

1) Do a fresh Checkout (using cl client or TortoiseSVN) into c:\foobar
2) modify a file inside c:\foobar, do *not* commit your changes
3) hit <f5> in Windows explorer to refresh the status overlay
4) try to delete c:\foobar using windows explorer or the dos box.
5) you will get an error like "c:\foobar\.svn\tmp is in use by another
process" (roughly translated from german)

This working copy stays wedged until you *completely* restart explorer.exe.

If you switch the background scan off, everything works as expected.

I reproduced the problem with a working copy that contains only one
file, which is checked out into c:\foobar\a.

Sysinternal's Process explorer shows the following thing happening:

- When fetching the status inside the WC (c:\foobar\a), explorer.exe has
two *\.svn\tmp file handles open after the first time fetching the
status. Each time I hit F5, the number of open handles increases by two.

- When fetching the status from the parent dir (c:\foobar), explorer.exe
has four *\.svn\tmp file handles open after the first time fetching the
status. Each time I hit F5, the number of open handles increases by four.

It looks like two file handles are leaked for each directory accessed
during status fetches.

Cheers & thanks
-Lübbe

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 15 17:00:44 2003