Compress Files/Folders (Table): Add option to make paths relative

Feedback & Ideas
,
1

Hi,

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

image
image1800×714 79.1 KB

I created a test workflow and saves the file “.test” but it seems not related to the presence of a dot.

image
image1105×428 12.6 KB

Best
Mike

2

I think the problem is the drive letters. That the one with the dot gets reported is just because it is the first one it validates.

Can you “relativize” the path string, e.g. by Path to String → Replace "E:\Knime-Workspace" with “” → String to Path?

1 Like
3

The path and drive seem legit … or do I miss something?

image
image738×892 35.5 KB

4

I think it will lead to a corrupt archive, since it cannot be unpacked on e.g. Linux, where drive letters are not a thing.

5

I start to get your point. Got to think about the compression parameters. Let me circle back when I got aa clear picture of that.

6

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.

7

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 verified that for Windows via:

Compress-Archive -Path "C:\Users\Mike Wiegand\Downloads\AWS logs\", "E:\Knime-Auth\" -DestinationPath "C:\Users\Mike Wiegand\Downloads\test.zip"

Something is odd, isn’t it?

8

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?

2 Likes
9

Agree and done … I will also test a few things later leveraging external commands.

1 Like