I'm having problem with the new External Tools (Labs) node not writing the input table to a file. If I use the 'generate unique file' option, I get this error (unix example):
ERROR External Tool (Labs) Execute failed: Can't access 'file:/var/folders/ka/kasEoO+DGq8W1m7ZFHvVVk+++TM/-Tmp-/wait_20110204_12967660805280/output/port0.csv'. (/var/folders/ka/kasEoO+DGq8W1m7ZFHvVVk+++TM/-Tmp-/wait_20110204_12967660805280/output/port0.csv (No such file or directory))
Watching that directory, at no time is anything appearing in the -Tmp- directory, which is the lowest level pre-existing directory in that above filepath.
If I specify filepaths in the node, I get the same error (with the specified filepath), but the file is never written. These filepaths work for the old External Tools node, so I don't think it's a directory permission error. I see the same problem on the Windows version of KNIME.
OS: tested Mac OS, WinXP
KNIME: 2.3.1
Input file: Column delimiter \t, Quote Character - blank
BTW, the new External Tool (Labs) node looks like being a great improvement on the old node, addressing several comments raised in the forum. Can I make a request? In addition to the %inFile% and %outFile% variables, could there also be an %arguments% variable so that arguments can be passed to the tool via flow variables?
It seems as it expects the given file to be generated by the tool. (I assume you simply do a "wait" to play around with the node? Maybe you want to do a "cp %inFile%"%outFile".)
Flow variables should be accessible with the syntax $(name-of-variable). This is an undocumented feature. Reason being that we are not certain about the syntax ("$() " overlaps with inline command execution in bash).
- Bernd
Sorry Bernd,
I'm not sure I follow your answer. As the incoming table is not written to %inFile%, it doesn't matter what external tool is used. "cp %inFile%"%outFile" exits with an error (just like every other tool) as %inFile% doesn't exist.
Simon
Hi Simon,
Sorry for the confusion, I was misled by the error message in your initial comment - it states that it is unable to locate the generated output.
I created a folder hierarchy /var/folders/ka/kasEoO+DGq8W1m7ZFHvVVk+++TM/-Tmp-/ on my system and things work as expected. Can you try to redirect your temp folder for moment? Change it globally in the preferences (File -> Preferences -> KNIME -> "Change directory of temporary data").
Could you also send the detailed stack traces (they should be in the log under <workspace>/.metadata/knime/knime.log)
Regards,
Bernd
Summary for forum:
Off-line Bernd and I have determined that:
1) The files are being written to the temp directory, but they are being deleted almost immediately when the error occurs, so I never see them.
2) The input table is written with RowIDs at the start of each row! This is not mentioned in the node description, and is not the default behaviour in the old node. It is these RowIDs that generate errors from the external tool.
3) I can use a shell script to remove the RowIDs and successfully process the table with the external tool, but the node expects RowIDs in the output, so the results are not read back in to the node.
Hopefully this information will help someone out there. And hopefully the release version of the node wil have the option back to turn off RowIDs in the table!
Simon
Hi,
I have precisely the same problem, but different info in the log file:
!ENTRY org.eclipse.osgi 2 0 2011-03-16 10:50:53.130
!MESSAGE The activator de.mpicbg.tds.knime.scripting.GroovyScriptingBundleActivator for bundle de.mpicbg.tds.knime.scripting.groovy is invalid
!STACK 0
org.osgi.framework.BundleException: The activator de.mpicbg.tds.knime.scripting.GroovyScriptingBundleActivator for bundle de.mpicbg.tds.knime.scripting.groovy is invalid
at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:156)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:751)
at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:370)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:284)
...
Caused by: java.lang.ClassNotFoundException: de.mpicbg.tds.knime.scripting.GroovyScriptingBundleActivator
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:506)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
I have KNIME 2.3.1 and R and Groovy scripting extensions for KNIME 1.0.1.0000522.
Where to find the missing class?
Thanks, best regards,
Harri
Hello again,
just to let you know, whatever the problem was, it seems to have been fixed in version 2.3.3.
Regards,
Harri
Hi,
Did your debugging process produce any workable solution?
I am facing the same problem now... If you have one, can you please send a working example?
Thanks,
Nir
No - I'm hoping that the final release version of the node will include an option to turn off RowId's and just read in the file from the external tool in the order presented.
(the other) Simon
I have a similar problem in Windows 7. I'm attempting to run obable.exe from the command line
obabel %inFile% -ofpt -xs -xf FP4 -u >%outFile%
and I am getting
ERROR External Tool (Labs) Execute failed: Can't access 'file:/C:/Users/myusername/AppData/Local/Temp/obabel_20130722_13744863671581/output/port0.csv'. (C:\Users\myusername\AppData\Local\Temp\obabel_20130722_13744863671581\output\port0.csv (The system cannot find the file specified))
Same problem trying to use obspectraphore.exe
I get the same problem:
ERROR External Tool (Labs) 0:934 Execute failed: Can't access 'file:D:/KNIME34/temp/Standardize_20180121_65579/output/port0.sdf'. (D:\KNIME34\temp\Standardize_20180121_65579\output\port0.sdf (Das System kann die angegebene Datei nicht finden))
The same workflow worked fine. Yesterday (January 20, 2018) there was an update for Windows 10. I changed the location of the temp files, I ran KNIME as admin, I created the directory ....Standardize_20180121_65579\output, but noting solved the problem.
Does anybody have an idea what the problem could be?
Alex
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.