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

Re: Deleting trouble

From: D.J. Heap <dj_at_shadyvale.net>
Date: 2003-12-16 04:10:45 CET

Lübbe Onken wrote:
> 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

Yes, if file handles are leaked then attempting to remove the directory
will fail -- no amount of retrying will help. The leak has to be fixed.

In the meantime, perhaps TSVN could be changed to clear and re-create
the client context for each operation if just clearing the main
pool/context gets rid of this problem.

I'm not sure the libraries were designed to expect long lived client
contexts and pools. I could be wrong, but I'm pretty sure there are
conditions (usually error conditions) where cleanup is just left to when
the pool gets cleared. Perhaps a core developer could shed some light
on the expected lifetime of the client's context/pool?

Is TSVN using a long-lived context/pool or is this an even nastier leak
that is not being freed even on pool cleanup? Presumably it is not
reproducible with the commandline client?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 16 04:11:38 2003

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

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