Lübbe Onken wrote:
[snip]
>
> 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?
DJ
---------------------------------------------------------------------
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