Holding on to pack files after disposing repository

When I try to delete the checkout location after calling Dispose() on the repository I get an exception "Access to the path 'pack-c2fbbbf1184a91086eb349987ee6502504fd29b3.idx' is denied."

I would have assumed that calling Dispose() would actually release all file handles. I read somewhere that the library holds on to some memory mapped pack files. Are they not being released correctly?

[ethomson]

Can you provide a short, self-contained example?

Not the exact same error, but this should work as well.

       [Test]
        public void Example()
        {
            var checkoutPath = Path.GetTempFileName();
            File.Delete(checkoutPath);
            Directory.CreateDirectory(checkoutPath);
            var repoPath = LibGit2Sharp.Repository.Init(checkoutPath);
            var repository = new LibGit2Sharp.Repository(repoPath);
            using (var w = File.CreateText(Path.Combine(checkoutPath, "Meh.txt")))
            {
                w.WriteLine("test");
            }
            repository.Index.Add("Meh.txt");
            repository.Commit("test");
            repository.Dispose();
            Directory.Delete(checkoutPath, true);
        }

[carlosmn]

Have you checked that the error isn't because those files are read-only but because we're holding on to them? I would expect the error message to say so, whereas an access-denied message sounds like the read-only behaviour for files on Windows.

If I look in the directory after the delete comman has thrown the exception I don't actually see any files in there (but retrying the delete doesn't work either).

And yes, I agree with you: it probably has nothing to do with permissions but with the library holding on to files.

[mglodack]

I've also come across this same issue.

UnauthorizedAccessException·Access to the path 'pack-55a7957d1e63c13a19598d13804ead41e418246c.idx' is denied.

[mglodack]

Took @roederja2 idea and created a test that verifies this issue.

I did some investigating, but didn't see anything obvious that would be holding onto the file.

master...mglodack:fix_holding_resource_issue

[gsaralms]

we have seen the same but that was because objects are marked as readyonly.

Using the below code we can delete the git directory without any issues:

    private static void DeleteDirectory(string directory)
    {
        foreach (string subdirectory in Directory.EnumerateDirectories(directory))
        {
            DeleteDirectory(subdirectory);
        }

        foreach (string fileName in Directory.EnumerateFiles(directory))
        {
            var fileInfo = new FileInfo(fileName)
            {
                Attributes = FileAttributes.Normal
            };
            fileInfo.Delete();
        }

        Directory.Delete(directory);
    }

[ethomson]

Yes, thank @gsaralms , this is exactly what I would expect to see. Git (and libgit2, and thus LibGit2Sharp) create object files without write permission, and this is by-design. As a consequence, you must make them writable before removing them.

[felixfbecker]

I am seeing this issue with PowerShell in CI when Pester tries to clean up the test folder with Remove-Item -Recurse -Force. What's interesting is that the failure is also on macOS and Linux, who don't have read only file attributes, only read/write permissions. Does LibGit2Sharp set specific permissions on macOS or Linux? Or is this caused by not calling Dispose()?
What's interesting is is that this only fails in CI.

[ethomson]

Does LibGit2Sharp set specific permissions on macOS or Linux?

On all platforms, git (and libgit2) will remove the write bit from object files. You will need to rm -rf or the platform equivalent or set the files writable before the cleanup step.

[felixfbecker]

Well it is using rm -rf

[ethomson]

It sounds like it's doing a PowerShell Remove-Item -Recurse -Force, not a literal rm -rf.

So either that PowerShell command really will try to remove unwritable files (which presumably is what the -Force flag does) and there's likely a permissions problem: what does ls -FlasR say about the git repository? How does that correspond to id?

Or it doesn't. Can you try actually running rm -rf on macOS/Linux?

This issue, as opened, is reporting that the library had a file open, which prevents it from being removed on Windows, due to sharing semantics. There are no such issues on POSIX systems, you can remove a file that is open, which will remove the directory entry (existing readers/writers will still have a file descriptor to the file).

So if you're seeing this on a POSIX system, there's a permissions problem.