Skip to content

Add UNIX file type bits when only permissions are given - #969

Open
maximilliangrand wants to merge 1 commit into
Stuk:mainfrom
maximilliangrand:fix/unix-permissions-file-type-bits
Open

Add UNIX file type bits when only permissions are given#969
maximilliangrand wants to merge 1 commit into
Stuk:mainfrom
maximilliangrand:fix/unix-permissions-file-type-bits

Conversation

@maximilliangrand

Copy link
Copy Markdown

Bug

Setting unixPermissions to a bare permission value - the "755" form shown in JSZip's own docs - writes an entry whose UNIX mode has no file-type bits:

const zip = new JSZip();
zip.file("script.sh", "#!/bin/bash", { unixPermissions: "755" });
const buf = await zip.generateAsync({ type: "nodebuffer", platform: "UNIX" });
// zipinfo shows:  ?rwxr-xr-x  ... script.sh   (unknown file type)

Cause

generateUnixExternalFileAttr() only fills in the file-type bits (S_IFMT) in its default branch, when no permissions are supplied (0100664/040775). A user-supplied value is written through unchanged, so a bare 0755 ends up with file-type 0. The default path and the user path therefore produce different-quality output.

Fix

When permissions are given but the S_IFMT bits are absent, add the regular-file / directory type, matching the default JSZip already uses. A value that already carries a file type (e.g. a 0120777 symlink, per #428) is left untouched.

Evidence

zipinfo on the same input after the fix: -rwxr-xr-x script.sh, drwxr-xr-x dir/, lrwxrwxrwx link (symlink type preserved). Added a round-trip test in permissions.js; it fails on main (755 vs 100755) and passes with the fix. Lint clean.

When unixPermissions is set to a bare permission value without the
S_IFMT file type bits (e.g. the documented "755" example), the
generated entry stored a mode with no file type, which tools that
inspect the UNIX file type (zipinfo, ...) report as an unknown type
("?rwxr-xr-x"). Fill in the regular-file / directory type bits in that
case, matching the default JSZip already uses when no permissions are
supplied. A mode that already carries a file type (e.g. a 0120777
symlink) is left untouched.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant