#797: zip symlink pure java

[shodiBoy1]

This PR fixes #797: fix VSCode install on macOS

Implemented changes:

• On macOS, installing VSCode was failing because the ZIP extractor could not handle .framework folders. These folders use symlinks that point to other symlinks (a chain). The old code tried to resolve the full path of each symlink before creating it, which fails when the next symlink in the chain does not exist yet.
• New behavior: write each symlink with the exact text from the ZIP, the same way unzip does. No path resolution, no existence check. The chain just works once all files are on disk.

---

Testing instructions

1. Check out the PR:
   gh pr checkout 1995

2. Run on a Mac:

• Open the project in IntelliJ.
• go to 'com.devonfw.tools.ide.cli.Ideasy' -> Modify Run Configuration.
• Program arguments: vscode
• Working directory: any empty folder (e.g. ~/test-ideasy).
• Click Run.

---

Checklist for this PR

• When running mvn clean test locally all tests pass and build is successful
• PR title is of the form #«issue-id»: «brief summary» (e.g. #921: fixed setup.bat). If no issue ID exists, title only.
• PR top-level comment summarizes what has been done and contains link to addressed issue(s)
• PR and issue(s) have suitable labels
• Issue is set to In Progress and assigned to you or there is no issue (might happen for very small PRs)
• You followed all coding conventions
• You have added the issue implemented by your PR in CHANGELOG.adoc unless issue is labeled
  with internal
• You have formulated clear instructions on how to test your contribution under "Testing instructions"

[coveralls]

Coverage Report for CI Build 27616583660

Coverage decreased (-0.03%) to 71.256%

Details

• Coverage decreased (-0.03%) from the base build.
• Patch coverage: No coverable lines changed in this PR.
• 159 coverage regressions across 3 files.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

159 previously-covered lines in 3 files lost coverage.

File	Lines Losing Coverage	Coverage
com/devonfw/tools/ide/io/FileAccessImpl.java	157	67.99%
com/devonfw/tools/ide/tool/ide/IdeToolCommandlet.java	1	78.33%
com/devonfw/tools/ide/version/VersionSegment.java	1	89.76%

---

Coverage Stats

Relevant Lines:	16212
Covered Lines:	12048
Line Coverage:	74.32%
Relevant Branches:	7250
Covered Branches:	4670
Branch Coverage:	64.41%
Branches in Coverage %:	Yes
Coverage Strength:	3.15 hits per line

---

💛 - Coveralls

[hohwille]

@shodiBoy1 thanks for your PR and your analysis of the root cause. I like that you always take such special problem and analyse it properly trying to come up with a rather small fixing PR👍
Surely we could merge this as is as a quickfix.
However, you revealed here that we have actually implemented our link function wrong (and therefore our "unpack" functions - not only for zip but also for tar).
IMHO your PR is not fixing that bug but adding a workaround with quite some redundancies.

My goal is that we aim for true quality so I would love to fix the link function properly.
Can you maybe extract a JUnit test that reproduces the scenario with invoking our link function?
BTW: We meanwhile also have ide ln -s <source> <link> to test such things. If you want to test with relative being true you can do ide ln -s -r <source> <link>.
If that is buggy, please lets fix the root cause.

[shodiBoy1]

Thanks for the review.

My initial idea was to preserve the raw symlink target from the ZIP entry, because macOS framework bundles can contain chained symlinks where the final target is created later. That is why I first handled ZIP symlinks directly.

After your feedback I agree that this was too ZIP-specific and bypassed the existing PathLink/link(...) abstraction. I reworked it so ZIP and TAR both go through PathLink -> link(PathLink), and the actual fix is now in the shared link handling.

The shared link code now avoids resolving symlink targets too early, so archive symlinks can point through links that are created later. I also added a regression test that calls FileAccess.link(PathLink) directly for the macOS framework-style case.

Tested with FileAccessImplTest, LnCommandletTest, and a manual VS Code install from IntelliJ.

[hohwille]

@shodiBoy1 thanks for rework. Now approach seems reasonable. Changing to approved 👍
Team-review should still test that link creation still works as expected and have a quick look again and the diff.

[tineff96]

Overall, the PR looks good to me.

I ran:

mvn clean test

Results:

• Ubuntu/WSL: passes without changes

• Windows: fails on this PR branch in:

  • testSymlinkShortcutPaths
  • testSymlinkAbsolutePassingRelativeSource

The Windows failures seem related to the mklink fallback. If relative == false, passing the relative source to mklink causes Windows to resolve it against the process working directory instead of the link parent directory.

I tested the following adjustment in FileAccessImpl.java, line 481:

Path finalSource = relative ? source : absoluteSource;

With this change, the focused test suite passes for me on Windows as well. This should keep the ZIP/macOS path able to preserve relative symlink targets when needed, while the Windows fallback keeps the previous absolute/adapted behavior for relative == false.

I still think the original macOS VSCode case should be verified manually on a Mac. I will ask a teammate with macOS to run the ide vscode scenario as well.