File system errors when using workspace on network drive

TL;DR:

When working with a KNIME workspace on a mounted network drive from Windows, trying to create a new workflow (as well as trying to save a workflow with data, in an executed state) results in errors that are linked to KNIME trying to set/unset the I=Indexed attribute, which is not supported by the backing storage.

The same thing works fine from Mac OSX (and presumably Linux), as these systems don't even know the I=Indexed file attribute.

I'd be grateful for any help solving this issue.

Background:

In our multi-user environment at FMI Basel, we have some imaging workstations and virtual machines that rely on a very fast network storage. We therefore wanted to allow users working with their own workspace on that network storage from any analysis workstation.

However, trying to create a new workflow results in the following error:

Could not write file:
\\network\path\KNIME-ws\Test File Attribute Bug\.project.

All the file permissions are granted, and we confirmed that the .project file even was created. After a debugging session with our storage expert, we found that this is due to KNIME asking the file system to change the Indexed file attribute after file creation. As this is a Windows-specific attribute, we also tried using the network-mounted workspace from Mac OSX, where it works without problems.

A similar error is shown when trying to save one of the example workflows after (paritally) executing it:

File access problems:
\\network\path\KNIME-ws\Example Workflows\Basic Examples\Building a Simple Classifier\.savedWithData

Here's some info from the knime.log file:

java.io.FileNotFoundException: \\network\path\KNIME-ws\Example Workflows\Basic Examples\Building a Simple Classifier\.savedWithData (Access is denied)
    at java.io.FileOutputStream.open0(Native Method)
    at java.io.FileOutputStream.open(FileOutputStream.java:270)
    at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
    at java.io.FileOutputStream.<init>(FileOutputStream.java:162)
    at java.io.FileWriter.<init>(FileWriter.java:90)
    at org.knime.core.node.workflow.FileWorkflowPersistor.saveContent(FileWorkflowPersistor.java:2051)
    at org.knime.core.node.workflow.FileWorkflowPersistor.save(FileWorkflowPersistor.java:1919)
    at org.knime.core.node.workflow.WorkflowManager.save(WorkflowManager.java:8155)
    at org.knime.workbench.editor2.InplaceSaveRunnable.save(InplaceSaveRunnable.java:92)
    at org.knime.workbench.editor2.AbstractSaveRunnable.run(AbstractSaveRunnable.java:104)
    at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:119)

Again, I confirmed that the file is actually present and has the following content:

Do not delete this file!
This file serves to indicate that the workflow was written as part of the usual save routine (not exported).

Workflow was last saved by user Vincenzo on Wed Nov 30 18:11:58 CET 2016

 

We are using plain Java API and are not setting any Windows-specific attributes. Maybe this is the default for Java under Windows? Can you try with a small Java program that does standard Java I/O?

Creating a `java.io.FileWriter` object and both creating and writing content into a file `.test` on the same location works fine from Java 1.8.0_121 (tested from within ImageJ).

I didn't have a chance yet to test with older Java versions. What's the Java version used in KNIME?

Were you able to reproduce the issue on your side with KNIME and a (non-NTFS) network storage?

 

We don't have any Windows network shares available at the moment.

Can you try using a plain Eclipse SDK and create a workspace and project on your network drive?

Thanks for the hint. I was able to reproduce the issue with plain Eclipse by simply creating a Java or Maven project.

It seems that this issue was reported long ago but still hasn't been fixed:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=255511

Also, this seems to be specific to only certain systems, as in my tests it worked well with a different, smaller NAS. :-/