Does zip.js retain executable permissions of extracted files?

[guest271314]

Does zip.js retain executable permissions of extracted files?

[gildas-lormeau]

zip.js has been designed to run in a browser, so it does not handle the permissions for you.

However, you can get the raw data for the permissions via the Entry#externalFileAttribute property. You also need to read the Entry#versionMadeBy property to know how to decode this raw value. Unfortunately, the specification gives no useful info to know how to achieve this, see https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.10.TXT (search for "external file attribute" and "version made by").

There are some info here: https://unix.stackexchange.com/questions/14705/the-zip-formats-external-file-attribute for the UNIX format. I guess the best option is to find some open-source code which implements this feature in another zip library.

[guest271314]

I don't necessarily think this is a problem with your library. I don't think Chromium/Chrome Streams Standard implementation should be hanging just because we use new Response(readable).blob() after we close the writable side of a TransformStream.

[gildas-lormeau]

The real problem is await entry.getData(writable), you want to call it without await. Thus await new Response(readble).blob() would not be hanging.

It's a "known" (i.e. I know it) issue related to error handling and it's my fault (I guess?). On paper, it should be possible to catch the error from the stream without using await and when calling Entry#getData() with a WritableStream object as parameter, thanks to WritableStream#abort(). In practice, I have some issues to make it work properly in all browsers because they act differently and the cause is not clear to me right now (i.e. it's probably my fault because I didn't read the manual enough).

A workaround is to call Promise#catch() on the promise returned by entry.getData(writable), and not await it. See for example the piece of code below which does something similar by using Promise.all() in a somewhat elegant way.

zip.js/tests/all/test-streams.js

Lines 20 to 26 in 2a10dda

	const firstEntry = entries.shift();
	const entryStream = new TransformStream();
	const [entryText] = await Promise.all([
	new Response(entryStream.readable).text(),
	firstEntry.getData(entryStream.writable),
	zipReader.close()
	]);

[guest271314]

I havn't read your source code, yet. From a Streams developer observation it shouldn't matter where or when the readable side of a TransformStream is read. Reading readable should not be dependent on what the writable side , nor where the reading or writing occurs in the code, particularly when we have control over the both pair.

I got your gist code working to fetch Chrome-For-Testing Canary Build https://gist.github.com/guest271314/8256d618b4a94ccc368c1a61e65e4cfa.

I'll keep trying to preserve executable permissions using only the browser. I'll first try creating the directory and setting files to size 0 named for expected executable files, set to executable, then overwrite the files, which should retain permissions.

[guest271314]

Looks like permissions are not retained using the code in the gist.

[guest271314]

For now I'm hardcoding the files that need to be set to executable

const executables = new Set([
  "chrome",
  "chrome-wrapper",
  "chrome_crashpad_handler",
  "chrome_sandbox",
  "libEGL.so",
  "libGLESv2.so",
  "libvk_swiftshader.so",
  "libvulkan.so.1",
  "nacl_helper",
  "nacl_helper_bootstrap",
  "nacl_irt_x86_64.nexe",
  "xdg-mime",
  "xdg-settings",
]);
// ...
async function unzip(args) {
  if (args.l) {
    await listEntries(args.l || args._[0]);
  } else {
    const archive = args._.shift();
    if (archive) {
      await unzipEntries(archive, args._);
      await Deno.remove("chrome-linux64.zip");
      for (const file of executables) {
        await Deno.chmod(`chrome-linux64/${file}`, 0o764);
      }
    }
  }
}