Sharpen.FilePath.Delete() failing randomly in NGit.Test tests

[dprothero]

I successfully compiled in Visual Studio 2010, Windows 7 x64, .NET 4.0.

Trying to run all the tests in the NGit.Test project, I randomly get an IOException when trying to delete a temporary file. Here's an example:

***** NGit.Api.CheckoutCommandTest.TestCheckoutWithNonDeletedFiles
System.IO.IOException: The process cannot access the file 'C:\Users\dprothero\Documents\GitHub\ngit\bin\target\trash\test1341438627296_62\temp' because it is being used by another process.
at Sharpen.FilePath.Delete() in C:\Users\dprothero\Documents\GitHub\ngit\Sharpen\Sharpen\FilePath.cs:line 148
System.IO.IOException: The process cannot access the file 'C:\Users\dprothero\Documents\GitHub\ngit\bin\target\trash\test1341438627296_62\Test.txt' because it is being used by another process.
at Sharpen.FilePath.Delete() in C:\Users\dprothero\Documents\GitHub\ngit\Sharpen\Sharpen\FilePath.cs:line 148

I can re-run the test and it'll pass, but another one will fail.

David

[alanmcgovern]

This is more than likely because the [Setup] and [Teardown] methods are not correctly setting up/cleaning up when each individual [Test] method is run. If you run tests individually then you won't hit this error as all open files will be closed when the test finishes.

If you can figure out which resources are not being disposed that'd be great. Linux and MacOS do not have this issue as the files are not 'locked' so can still be deleted.

[dprothero]

Well, I've verified the Setup and Teardown have the right cleanup code in them. In fact, it's the call to RecursiveDelete(TestId(), trash, false, true); in the TearDown method LocalDiskRepositoryTestCase, which is what a lot of the tests inherit from, that is throwing the error.

So, the teardown is failing to remove the trash folder because the operations that ran within the test actually are leaving the files open. I'm not sure where to begin to investigate that.

I noticed some comments about trying to call GC.Collect() to force files to close, but that's not any guarantee that your objects will be disposed of at any predictable time. The general best practice is to avoid calling GC.Collect(), but perhaps in Java it's more common (I'm not a Java programmer).

Not sure if I have the time to invest into what it would take to squash this one.

[alanmcgovern]

That's my feeling too. The tests are currently running on our build machines and are green there. However if they start failing I'll definitely look into getting this fixed properly.

[dprothero]

Your build machines not being Windows, I assume?

[dprothero]

Could this be at all related to issue #34? If it is using the Posix library on Windows?

[alanmcgovern]

We have Windows, MacOS and Linux machines all compiling and running the tests, but on Windows I think we are running them from a cygwin environment. JGit detects this scenario and uses different codepaths as compared to a plain windows environment. I suspect this is the case as I encountered a blocking bug when running the tests normally on Windows which I fixed with commit efc6de2.

I've asked internally about how we run the tests and if we are running them under cygin, I'm going to get another build lane set up which runs them normally.

[alanmcgovern]

Are these tests still randomly failing with the latest code in git?

[dprothero]

Yes