Unable to save a Component

Receiving the following message when trying to save an existing component to a folder in the Local Workspace:

“ERROR LocalWorkspaceFileInfo” - “Problem reading template type”

Further testing shows that saving the Component (ie. Component> Share) to a folder where it has never previously been saved to is successful - it is only when trying to save the Component subsequently that the issue arises.

Hi @mpk -

Welcome to the forum. Sorry for the trouble, but I’m not able to reproduce the problem here. When you share the component to your local workspace, on a subsequent second share, are you disconnecting the link first? (I couldn’t come up with your problem in either case.)

Could you please list the exact steps that lead to the bug being reproduced reliably?

Also, what version of KNIME are you using, and on which OS?


Hey @ScottF

You are correct, I have disconnected the link, edited the component and am attempting to again add the share. Please note however that this does not consistently occur across all components that I have (which is the cause for my delayed response).

Foe the record, following are version details:

As there is an update, I will install same, retry and advise of the outcome.



cc. OpexVFGLmapping

Upgrading has not resolved the issue.

OS is Windows:

Hi @mpk -

Thanks for the feedback. I will try a few more things to come up with a consistently reproducible problem, and if I can do so, I’ll create a ticket. (And if you are able to come up with a set of reproducible steps please do post them here!)


1 Like

@ScottF I can confirm the observed issue. It just happened to me a few times today. Steps to reproduce (not sure if always happens):

  1. Drag and drop a linked component to a workflow
  2. Unlink the component
  3. Change something in the component
  4. Try to overwrite the existing component (Share)

I also observed that the error message (ERROR LocalWorkspaceFileInfo Problem reading template type) now always shows up in the log if I try to right-click on the existing shared component in the KNIME Explorer. Because I wanted to delete the existing component in order to be able to share the new one. So it seems to be some overwriting issue. At some stage the linked component seems to become corrupt.

My shared component looks like this:


I got KNIME 4.1.1 and my packages are:

1 Like

So far my current (hack) fix is:

  1. Delete the workflow through the windows explorer
  2. Refresh the folder in the KNIME Explorer
  3. Share the component again which is not showing up in the KNIME Explorer anymore

Thanks @dobo for the detailed steps. I’ll see if I can find a system here that will reproduce the problem.

Does this completely prevent the issuing from recurring? I believe that when I had deleted the item via Explorer it didn’t resolve the issue from occurring when sharing the second time.

no, sadly this only helps me to continue my work until a real fix is found

Hi @dobo,
can you still reproduce it? If so, can you maybe provide us the full stack trace of the problem from the KNIME log?
In order to do so choose in the menu View > Open KNIME log, search for ‘Problem reading template type’ and copy the entire error message including the stack trace (… at … at …at …).
I hope that’ll give us more insights to figure out what’s going on there.


1 Like

sadly no :confused: I’ll let you know once I encounter it again. It seems to be related to other things I did previous to that step but I can’t find out what. It might be related to heavy editing of nested shared components

Hi @hornm,

it happened again! :partying_face:

Actually the issue causes the shared component to be persistently corrupt (error is also thrown after a restart of knime). so I really need to go to the file system over the windows explorer and delete the old component.

I think I am a bit closer now about in what context this fails. I think it really has to do with the editing of shared components. This is what I think I did previous to the error:


  1. Create one workflow
  2. create a component in this workflow and share it to the same workflow group
  3. create a new workflow
  4. pull the shared component into the workflow
  5. save & close everything
  6. restart of knime, as the above described setup was created days before the actual issue happened

Actual procedure to provoke the error:

  1. open one of the two workflows with the shared component
  2. edit the shared component and change something inside the component (add a node) and also change the name of the component by right-clicking on it and selecting “component -> setup”
  3. share the component in the same workflow group
  4. open the second (previously created) workflow
  5. pull the new shared component into the second workflow
  6. delete the old component from the second workflow
  7. right-click on the shared component in the “KNIME Explorer”

-> with the right-click on the shared component in the “KNIME Explorer” the exception is thrown. This is the only relevant hint I found in the log:

2020-02-26 15:53:41,268 : ERROR : main :  : LocalWorkspaceFileInfo :  :  : Problem reading template type
java.lang.IndexOutOfBoundsException: Index: 0
    at java.util.Collections$EmptyList.get(Collections.java:4454)
    at org.knime.core.util.workflowalizer.Workflowalizer.populateComponentFields(Workflowalizer.java:879)
    at org.knime.core.util.workflowalizer.Workflowalizer.readTemplateMetadata(Workflowalizer.java:516)
    at org.knime.core.util.workflowalizer.Workflowalizer.readTemplate(Workflowalizer.java:344)
    at org.knime.workbench.explorer.localworkspace.LocalWorkspaceFileInfo.isComponentTemplate(LocalWorkspaceFileInfo.java:244)
    at org.knime.workbench.explorer.localworkspace.LocalWorkspaceFileInfo.isComponentTemplate(LocalWorkspaceFileInfo.java:156)
    at org.knime.workbench.explorer.view.ExplorerView.fillContextMenu(ExplorerView.java:699)
    at org.knime.workbench.explorer.view.ExplorerView.access$10(ExplorerView.java:686)
    at org.knime.workbench.explorer.view.ExplorerView$7.menuAboutToShow(ExplorerView.java:676)
    at org.eclipse.jface.action.MenuManager.fireAboutToShow(MenuManager.java:339)
    at org.eclipse.jface.action.MenuManager.handleAboutToShow(MenuManager.java:470)
    at org.eclipse.jface.action.MenuManager.access$1(MenuManager.java:465)
    at org.eclipse.jface.action.MenuManager$2.menuShown(MenuManager.java:497)
    at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:256)
    at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:86)
    at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4428)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1079)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1103)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1084)
    at org.eclipse.swt.widgets.Control.WM_INITMENUPOPUP(Control.java:5204)
    at org.eclipse.swt.widgets.Control.windowProc(Control.java:4872)
    at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:359)
    at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1657)
    at org.eclipse.swt.widgets.Shell.windowProc(Shell.java:2199)
    at org.eclipse.swt.widgets.Display.windowProc(Display.java:5178)
    at org.eclipse.swt.internal.win32.OS.TrackPopupMenu(Native Method)
    at org.eclipse.swt.widgets.Menu._setVisible(Menu.java:262)
    at org.eclipse.swt.widgets.Display.runPopups(Display.java:4279)
    at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3811)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1150)
    at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1039)
    at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:153)
    at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:680)
    at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
    at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:594)
    at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
    at org.knime.product.rcp.KNIMEApplication.start(KNIMEApplication.java:149)
    at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:653)
    at org.eclipse.equinox.launcher.Main.basicRun(Main.java:590)
    at org.eclipse.equinox.launcher.Main.run(Main.java:1499)

I hope this helps!

1 Like

Hey @hornm, any update on this one? I found that once a workflow is corrupted like that I seem not to be able to rename any of the parent or grandparent directories up to the LOCAL workspace root anymore (KNIME locks for a very long time (5 minutes) and then shows the “Problem reading template type” error message), which makes the administration of projects quite difficult. I’m looking forward to a fix!

Hi @dobo,
sorry to hear that!
I tried hard to reproduce it on my computer (linux). Unfortunately without success so far. Will setup windows and try it there.
There might be a slight chance that the issue is resolved meanwhile (in the nightly build, i.e. future AP 4.2) by a fix done for another problem.

The fix should be in the 4.1.3 release, which was released May 14.
Can you double check this is working for you?

1 Like

Hi Iris,

It took me a while to test this again :innocent:

And yes this seems to be fixed in 4.1.3! Thank you!


1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.