Community
Participate
Working Groups
Steps to reproduce In Git perspective: * Clone Git repository using "Clone a Git repository and add the clone to this view" button. * After that remove the repository using "Del" key. In the dialog click on "Remove from View" button. * Switch to e.g. Windows Explorer and try to remove the repository or move it to another location. Result: The last step cannot be performed as some of the files in the repository are still opened. Expected: The repository can be (re-)moved as it was disconnected from Eclipse. Notes: * The cloned project was not imported into Eclipse as a project, e.g. "Project Explorer" view stays empty all the time. * After closing Eclipse, Git projects could be (re-)moved. Additional info: * Eclipse 4.11.10 (2019-03) * Git integration for Eclipse (org.eclipse.egit.feature.group) v5.3.0.201903130848-r
*** This bug has been marked as a duplicate of bug 439305 ***
I don't think this is a duplicate of 439305. In the scenario given in comment 0 Repository.close() is indeed never called. The repo directory is removed from the "configured repos" persisted setting and thus removed from the view, but the Repository instance isn't closed and it still remains in the EGit RepositoryCache. Not closing it yet is correct since it might still be referenced from elsewhere. (In the given scenario it probably isn't, though, but in general it might be referenced in other views or in background jobs.) Java garbage collection will then reclaim the Repository object once it's only weakly referenced, but that won't call close(). There's several aspects here: 1. The Repository indeed will not vanish immediately from EGit; that will happen only when the object is garbage collected. We cannot reasonably change that; it would mean a global change in EGit using some kind of handles and reference counting to access Repository objects. I'm not sure that even that would help. 2. When the object is garbage collected, it isn't closed. That could perhaps be fixed, but it's non-trivial, too. I'm experimenting with some ideas for this, but it's not ready yet. 3. With submodules it could also be that while the top-level repository is removed from EGit a submodule repository is still used, and deletion of the top-level repo's .git directory thus might still not work. I don't see any solution for this case.
I still think it's a duplicate. Adding a repo.close() call in the repo node removal doesn't change the symptomes. The pack files are locked with or without that call.
Probably related to bug 455005. It looks like some index-files are not closed. Debugging in eclipse shows exception with files like ...\.git\objects\pack\pack-cdb89079241c950db1332ca52dfc75f930c71669.idx We use eGit 5.4.0 - and really welcome any improvement on this.
Is there any progress on this ?
(In reply to kurt ablinger from comment #5) > Is there any progress on this ? No. But we welcome Gerrit changes in that area. Bear in mind that all contributors to EGit/JGit are volunteers; they'll follow their own priorities and do what's most urgent for them, not for the users. Often these interests will overlap, but sometimes they don't. Fixing this for good is a hard problem, too. Even figuring out what exactly changed between 5.2 and 5.4 (judging from your comment at bug 455005) so that the problem now apparently occurs more frequently is hard. Point 1 and 2 from comment 2 exist in both (if fact, in all) EGit versions. Finally, JGit 5.4.0 has some problems with file handling, which I strongly suspect (though I cannot prove it) may contribute to a number of strange bugs suddenly cropping up, such as this, or also bug 548716 or bug 549178.
New Gerrit change created: https://git.eclipse.org/r/146469
New Gerrit change created: https://git.eclipse.org/r/146471
Gerrit change https://git.eclipse.org/r/146471 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=27f697e7169474370f6e7b24f7e4364a074048cd
New Gerrit change created: https://git.eclipse.org/r/152108
Gerrit change https://git.eclipse.org/r/152108 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=528a53b2793a5f86c3f372e4b36e0933a0c481d6
Repository closing is fixed as far as it can be fixed in EGit. See comment 2. EGit still uses a WeakReference cache, but now also ensures that repositories are closed when no longer referenced. This still does not guarantee _immediate_ closing, but repositories will be closed eventually, when the garbage collector decides to garbage collect them. Which should occur pretty soon with weak references. Can also be triggered manually ("Preferences->General->Show Heap Status", then click the trash can icon in the status bar at the bottom of the Eclipse window.) And there's still the possibility that despite closing some file handles are not closed properly by JGit; see bug 439305. Closing this EGit bug for now.
