I have a workflow that processes a number of files and one of the steps is decompression. I get the following error:
Unsupported feature data descriptor used in entry file_of_interest/RunInfo/SciRunStats.sts.lock
This file can be decompressed using 7 zip but the output creates two folders. The unziped folder and a folder _MACOSX which also contains the folder of interest.
Does anyone have any experience on why this is happening. Searching the error points to this page:
But it’s not clear if there is a way around this.
Thanks in advance,
Can you provide some more details about these zip files that you are using, are they encrypted or password protected? It would help us understand the problem in more detail.
Thanks for the response. I’m not sure as these files do not originate with me but I can unzip them with no issues using 7zip for example. Is there a place where I can find some metadata which would be helpful? I can see no obvious difference between this file and other zip file in which I am processing.
I did look a the permissions and there were no differences in that file and others which could be decompressed. Same owner and permissions. Now, I did decompress and recompress the contents of the folder and it worked fine. It did change ownership to me but I’m thinking it must be something else as this is the only file which behaved like this.
That’s quite strange. If possible, could you provide an example of a file that fails, and the same file working after you unzipped it / rezipped it outside of KNIME? There might be some strange encoding in the original zip that the node isn’t dealing with properly.
I understand if these file are proprietary and you can’t share them, but I think we need example files to be able to track the issue down at this point.
You are correct in that the data is sensitive. let me see if I can remove/replace the sensitive data while keeping the same issue.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.