Skip to content

test: fix zipinfo non-ascii check in test-zlib-zip-interop - #66978

Open
ravi-arnan wants to merge 1 commit into
nodejs:mainfrom
ravi-arnan:test-zlib-zipinfo-unicode
Open

ravi-arnan wants to merge 1 commit into
nodejs:mainfrom
ravi-arnan:test-zlib-zipinfo-unicode

Conversation

@ravi-arnan

Copy link
Copy Markdown
Contributor

Fixes: #66975

Problem

In test/parallel/test-zlib-zip-interop.js, zipinfoUnicode is evaluated as /UNICODE_SUPPORT/.test(unzip -v). However, stock Info-ZIP builds (common on Linux distros such as NixOS, Arch Linux, Alpine, and Debian) still sanitize non-ASCII bytes to '?' in fnfilter() unless patched with wide-character/UTF-8 printing support (e.g. USE_NATSPEC or alt-iconv-utf8-print).

On these systems, zipinfo outputs unicode-??.txt (or unicode-??????.txt) instead of unicode-名前.txt, which causes the assertion:

assert.ok(zipinfo.stdout.toString().includes(name), `zipinfo missing ${name}`);

to fail.

Solution

When checking zipinfo output:

  • First check if the entry name matches verbatim (as on patched Info-ZIP builds).
  • If not and the entry name contains non-ASCII characters, verify that zipinfo listed the entry with '?' placeholders.
  • If an entry is missing entirely (or if a plain ASCII entry is missing), fail the assertion.

The actual UTF-8 decoding and round-trip extraction continue to be verified by bsdtar directly afterwards.

Verification

  • Ran Node.js ESLint: node tools/eslint/node_modules/eslint/bin/eslint.js test/parallel/test-zlib-zip-interop.js (clean, 0 warnings/errors).
  • Verified against real zipinfo execution on Linux (NixOS) where stock Info-ZIP prints unicode-??.txt (clean pass).

@nodejs-github-bot nodejs-github-bot added needs-ci PRs that need a full CI run. test Issues and PRs related to Node.js core tests and test infrastructure. labels Oct 24, 2026
@github-actions

Copy link
Copy Markdown
Contributor

Welcome to Node.js, and thank you for your first contribution!

Before review, please take a moment to read:

Please make sure every commit is signed off. For a first pull request, GitHub Actions require collaborator approval and Jenkins CI must be started by a collaborator or triager, so an initial wait is normal.

@vedchaudhari

Copy link
Copy Markdown
Contributor

Hi @ravi-arnan, thanks for working on this! Two things I noticed:

  • It fails on macOS. Since the UNICODE_SUPPORT check is removed, macOS now checks the Japanese name too. But Apple's zipinfo doesn't turn the whole name into ?s, it keeps some of the bytes: 名前 comes out as e5 3f 3f e5 3f 3f. So the \?+ pattern doesn't match and the test fails: https://github.com/vedchaudhari/node/actions/runs/40075440958
  • Debian, Arch and Alpine actually print the name fine. The description and the new comments say they show ?, but those distros turn the ? filter off (NO_WORKING_ISPRINT). I checked on Ubuntu and it printed unicode-名前.txt. The ? only shows up on builds that keep the filter on, like Gentoo with USE="unicode -natspec".

I opened #66979 with a version that keeps the UNICODE_SUPPORT check, in case that helps. Happy to go with whichever the reviewers prefer!

Keep UNICODE_SUPPORT guard so macOS skips checking non-ASCII names
in zipinfo output, and accept '?' / U+FFFD placeholders on builds
with UNICODE_SUPPORT that filter non-ASCII bytes in fnfilter()
without wide-character printing support (such as NixOS or Gentoo).

Fixes: nodejs#66975
Signed-off-by: Ravi Arnan <raviarnankeren@gmail.com>
@ravi-arnan
ravi-arnan force-pushed the test-zlib-zipinfo-unicode branch from 288cb78 to d64e99d Compare October 24, 2026 10:50
@ravi-arnan

Copy link
Copy Markdown
Contributor Author

Hi @vedchaudhari, thanks for the review and for catching the macOS behavior!

I reproduced and verified this directly on a physical macOS machine (Darwin 21.6.0, built-in Info-ZIP 6.0). As you noted:

  • Apple's Info-ZIP build does not report UNICODE_SUPPORT in unzip -v.
  • Its fnfilter() keeps 0xe5 (since isprint(0xe5) is true under the default 8-bit table) but replaces continuation bytes with ?, giving \xe5??\xe5?? (e5 3f 3f e5 3f 3f), which decodes as \uFFFD??\uFFFD?? in UTF-8.

I have updated this PR to:

  1. Restore the zipinfoUnicode check so platforms lacking UNICODE_SUPPORT (such as stock macOS) continue to skip the zipinfo non-ASCII assertion, preserving baseline behavior.
  2. For systems with UNICODE_SUPPORT where fnfilter() still sanitizes non-ASCII bytes without wide-character printing (e.g. NixOS or Gentoo without natspec), normalize runs of ? and \uFFFD to match the non-ASCII placeholder.

Linter and test assertions are verified clean.

@codecov

codecov Bot commented Oct 26, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.60%. Comparing base (1eb734d) to head (d64e99d).
⚠️ Report is 30 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main   #66978      +/-   ##
==========================================
+ Coverage   90.58%   90.60%   +0.01%     
==========================================
  Files         797      797              
  Lines      278298   278298              
  Branches    53523    53518       -5     
==========================================
+ Hits       252095   252140      +45     
+ Misses      16570    16519      -51     
- Partials     9633     9639       +6     

see 35 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

needs-ci PRs that need a full CI run. test Issues and PRs related to Node.js core tests and test infrastructure.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

test/parallel/test-zlib-zip-interop.js fails if system's zipinfo is built without natspec

3 participants