Creating a repo locks files when it doesn't need to?

[MattSable]

I have the following scenario:

• Init/Clone a repo
• An exception happens
• Try to delete the repo during exception handling
• Get the following error:

The process cannot access the file because it is being used by another process: 'c:\users\testuser\1515512906fdd749\.git\objects\pack\pack-60818aaa1af2cbb2dc09737a822fed53f6ad08be.idx'

I've tried adding this to the exception handling before deleting the repo:

repo = porcelain.open_repo(repo_path)
repo.close()

which works sometimes, but not in all scenarios.

I've found that if I always just close the repo immediately after init/clone, and then just reopen it, I never run into any issues when trying to delete the repo later:

repo = porcelain.init(path)  # or porcelain.clone(...)
repo.close()
repo = porcelain.open_repo(repo.path)

This should mean that one of the two is true:

1. Init/Clone shouldn't be maintaining the lock on the .idx files, and this is a bug
2. There are some unintended consequences to my code that I just haven't run into yet.

@jelmer Do you know which of these two is the case?

[jelmer]

Calling .close() should be the right thing to do. However, you need to call .close() on the actual repository handle that is still active. What kind of code is triggering the exception? Is it working with the repository?

[MattSable]

The most recent issue i've been running into was with porcelain.push() correctly failing. All the exception handling is done in a different area of the code though, so I don't have access to the original handle.

Is there any downside that you know of to just closing the repo immediately after creating it like I have above?

[jelmer]

Actions that touch the repo afterwards can leave open handles that need to be closed. Calling close() after the repo is opened is not sufficient; you need to call close after the last operation that touched the repo. For example, after you've accessed some objects, Dulwich will have open handles to the packs that those objects are stored in. This is done intentionally for performance reasons.