NEW DATE! Bugzilla will undergo maintenance 2024-03-28 18h00 CET. Bugzilla will be placed in read-only mode at that time.

Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 565634 - Saving Git team provider data to X failed
Summary: Saving Git team provider data to X failed
Status: RESOLVED FIXED
Alias: None
Product: EGit
Classification: Technology
Component: Core (show other bugs)
Version: 5.3   Edit
Hardware: PC Windows 10
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-29 06:22 EDT by Lucas Koehler CLA
Modified: 2020-08-23 17:42 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lucas Koehler CLA 2020-07-29 06:22:37 EDT
Hello,

we use EGit programmatically to check out various projects. Sometimes, an error like the following is logged:

Saving Git team provider data to X failed

The log entry does not contain any stack trace. X is a file path. After this message, the error log is spammed with "Git team provider configuration has gone missing" messages like this:

!ENTRY org.eclipse.egit.core 4 0 2020-05-06 09:45:59.366
!MESSAGE Git team provider configuration has gone missing.
!STACK 0
java.nio.file.NoSuchFileException: D:\some\product\workspace\.metadata\.plugins\org.eclipse.core.resources\.projects\SomeProject\org.eclipse.egit.core\GitProjectData.properties
	at sun.nio.fs.WindowsException.translateToIOException(Unknown Source)
	at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
	at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
	at sun.nio.fs.WindowsFileSystemProvider.newByteChannel(Unknown Source)
	at java.nio.file.Files.newByteChannel(Unknown Source)
	at java.nio.file.Files.newByteChannel(Unknown Source)
	at java.nio.file.spi.FileSystemProvider.newInputStream(Unknown Source)
	at java.nio.file.Files.newInputStream(Unknown Source)
	at org.eclipse.egit.core.project.GitProjectData.load(GitProjectData.java:622)
	at org.eclipse.egit.core.project.GitProjectData.get(GitProjectData.java:222)
	at org.eclipse.egit.core.GitProvider.getData(GitProvider.java:108)
	at org.eclipse.egit.core.project.RepositoryMapping.getProjectData(RepositoryMapping.java:340)
	at org.eclipse.egit.core.project.RepositoryMapping.findMapping(RepositoryMapping.java:356)
	at org.eclipse.egit.core.project.RepositoryMapping.getMapping(RepositoryMapping.java:296)
	at org.eclipse.egit.ui.internal.decorators.DecoratableResourceAdapter.<init>(DecoratableResourceAdapter.java:53)
	at org.eclipse.egit.ui.internal.decorators.DecoratableResourceMapping.<init>(DecoratableResourceMapping.java:75)
	at org.eclipse.egit.ui.internal.decorators.GitLightweightDecorator.decorateResourceMapping(GitLightweightDecorator.java:260)
	at org.eclipse.egit.ui.internal.decorators.GitLightweightDecorator.decorate(GitLightweightDecorator.java:199)
	at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:256)
	at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:107)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
	at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(LightweightDecoratorManager.java:380)
	at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:362)
	at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:350)
	at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:313)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)


I tracked down the original error (Saving Git team provider data to X failed) to GitProjectData's store method. As I see it, it can only originate from one piece of code in the store() method:
if (!tmp.renameTo(dat)) {
	if (tmp.exists())
		FileUtils.delete(tmp);
	throw new CoreException(
			Activator.error(NLS.bind(
					CoreText.GitProjectData_saveFailed, dat), null));
}

This means the renameTo call must fail. From then on this is broken "forever" because the load() method just fails with the exception above when GitProjectData.properties is missing.

To clone and register the projects programmatically, we clone the repository with JGit and then:
final RepositoryUtil repositoryUtil = org.eclipse.egit.core.Activator.getDefault().getRepositoryUtil();
repositoryUtil.addConfiguredRepository(cloneDir);

Afterwards, we import the project into the Eclipse workspace and connect it like so:
// project is an IProject and repoDir a File
final ConnectProviderOperation cpo = new ConnectProviderOperation(project, repoDir);
cpo.execute(new NullProgressMonitor());

Besides the issue described in this bug, this works as expected and on Linux and Mac we never had any issues. Is this the correct way to do it?

Note: I know that 5.3 is quite old but I checked the GitProjectData#store method's code on the master branch and it did not change.

Thanks in advance for any feedback.
Comment 1 Thomas Wolf CLA 2020-07-29 06:45:44 EDT
Take a look at AbstractGitCloneWizard.importProjects(). That's what EGit uses to import projects from a freshly cloned repository.
Comment 2 Eclipse Genie CLA 2020-08-06 15:03:45 EDT
New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/167368
Comment 4 Thomas Wolf CLA 2020-08-23 17:42:27 EDT
(In reply to Eclipse Genie from comment #3)
> Gerrit change https://git.eclipse.org/r/c/egit/egit/+/167368 was merged to
> [master].
> Commit:
> http://git.eclipse.org/c/egit/egit.git/commit/
> ?id=31bcfac03da2deacea234bdfea9846e8c6ebba23

Not sure if that change resolves this, or if your way to check out and set up projects lacks an IWorkspaceRunnable somewhere.

Closing for now. Feel free to reopen if it still occurs and you can give some hints about why the rename might have failed.