I am close to finishing a workflow which allows me to backup my workspace i.e. to AWS S3. Using the Compress Files/Folders node to pass just a single folder path works but doing the same, i.e. to in-/exclude the data directory, fails with the following error:
2024-09-04 21:47:12,889 ERROR Compress Files/Folder (Table) 4:33 Execute failed: The archive entry name 'E:\Knime-Workspace\01_Example_for_the_external_tool_(Linux_or_Mac_only)\.savedWithData' associated with 'E:\Knime-Workspace\01_Example_for_the_external_tool_(Linux_or_Mac_only)\.savedWithData' results in an illegal/insecure archive
It’s actually forbidden to use drive letters per the ZIP spec:
4.4.17.1 The name of the file, with optional relative path.
The path stored MUST not contain a drive or
device letter, or a leading slash. All slashes
MUST be forward slashes ‘/’ as opposed to
backwards slashes '' for compatibility with Amiga
and UNIX file systems etc. If input came from standard
input, there is no file name field.
So, I guess the node does not relativize the paths for you like zip on Linux does. Hence, my suggestion to strip the Path prefix “E:\Knime-Workspace” (at least the drive letter).
I would personally also remove the workspace folder name from the path, because the ZIP then contains only the workspace contents and not its enclosing folder, but I think that would be personal preference.
Somehow reasonable … so it’s an oversight or a regression in the Compress Files/Folders then? Call me a liar but I recall that you can pass a list of absolute paths like so:
zip -r /home/user/archive.zip /home/user/folder1 /home/user/folder2
I suspect the node implementation just opted to disallow absolute paths with drive letters than to automatically relativizing them without the user noticing. zip and Compress-Archive seem to go for the latter approach. I tested with zip on macOS and it just strips the leading / if I feed absolute paths. Which you can verify by unzip -l /home/user/archive.zip, which shows the names which do not have a leading slash.
Anyway, either approach leads to spec-compliant ZIPs. But I think this thread could be reworded as “Compress Files/Folders (Table): Add option to make paths relative”. What do you think?