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?
Thanks!
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.
Regards,
Michael.
cc. OpexVFGLmapping
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!)
Thanks!
@ScottF I can confirm the observed issue. It just happened to me a few times today. Steps to reproduce (not sure if always happens):
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:
So far my current (hack) fix is:
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.
Thanks!
Martin
sadly no 
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! 
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:
Prerequisites:
Actual procedure to provoke the error:
-> 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!
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?
Hi Iris,
It took me a while to test this again 
And yes this seems to be fixed in 4.1.3! Thank you!
Best,
Dominic
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.