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

[mwiegand]

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

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

Best
Mike

[hotzm]

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?

[mwiegand]

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

[hotzm]

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.

[mwiegand]

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.

[hotzm]

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.

[mwiegand]

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?

[hotzm]

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?

[mwiegand]

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

[mwiegand]

Coming back to this I start to believe it is a serious bug (on Windows). On Linux the folder structure is different. Mounts are located under /mnt/ not necessarily requiring drive letters.

Contrary, though, Windows requires them. Otherwise attempting to compress data would fail as the path would be invalid:

Good: E:\Knime-Workspace\20_Blend_Languages_in_Tag_Cloud\
Bad: \Knime-Workspace\20_Blend_Languages_in_Tag_Cloud\

Manually testing things I noticed tar is throwing kind of a warning but still proceeds. Could it be that the Compress node unintentionally errors out?

PS: It seems the Compress Files/Folders node already ensures that Path-data is made relative under certain circumstances but … then errors out:

2024-10-01 20:10:07,456	ERROR Compress Files/Folder (Table) 3:33       Execute failed: file name 'Knime-Workspace/20_Blend_Languages_in_Tag_Cloud/.artifacts/workflow-configuration-representation.json' is too long ( > 100 bytes)

2024-10-01 20:12:29,356	ERROR Compress Files/Folder 3:1415     Execute failed: file name 'Knime-Workspace/20_Blend_Languages_in_Tag_Cloud/.artifacts/workflow-configuration-representation.json' is too long ( > 100 bytes)

Manually configuring another workflow it worked.

Testing yet another seems to isolate the issue to data in the folder “.artefacts” but the first one got the folder too What on earth is going on with that node?

2024-10-01 20:16:36,215 ERROR Compress Files/Folder 3:1415 Execute failed: file name 'Knime-Workspace/atMedia Onine Marketing/Nginx Log Analysis/170524 Nginx Server Log Analysis/.artifacts/workflow-configuration-representation.json' is too long ( > 100 bytes)

Best
Mike