From 8cd7e467ebec987f66c4fe93a8d87dfbc57304d2 Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Sat, 15 Aug 2026 12:19:22 +0200 Subject: feat(files): download a folder as a zip, and remove an empty one MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Two things a Files panel needs and did not have. **Removing a directory** is privileged, where creating one is not: it acts on a name other members are using, on the operator's disk. It is refused unless the directory is empty, and that rule is the safety property — whatever the browser sends, this cannot destroy content. The check runs twice, once before the challenge and once after the signature comes back, because a file can land during the round trip. A file also accepts its uploader's key; a directory has no uploader, so only the operator's key will do. **Downloading a folder** produces a zip built in the browser, written straight to disk as the chunks arrive. An archive of a group folder is routinely tens of gigabytes, so nothing is held: peak memory is one chunk plus a small record per file. The node is not involved at all — it serves the same encrypted chunks as any other download, holds no temporary files, and cannot be asked to compress anything. zipstream.js is store-only. Group content is video and images, already compressed, so deflate would spend CPU on every byte to save nothing, in the thread that is also decrypting. Sizes and CRCs go in a data descriptor after each file because a stream cannot seek back to patch a header, and zip64 kicks in per entry past 4 GiB and for the archive itself. Because none of that can be checked from the Python side of the house, test_zipstream.py runs the real module under Node and reads what it produces with zipfile — CRCs, UTF-8 names, zip64 records and all. The archives also pass `unzip -t`. Firefox and Safari have no File System Access API, so there is nowhere to stream to: the fallback builds the archive in memory and says so, with the size, before starting rather than after failing. One mistake worth recording: the first version of deleteDirectory passed the node's own answer as the value to check the challenge against, which turns the comparison into a tautology. It checks the path we asked for. Co-Authored-By: Claude Opus 5 --- packages/meshbay-hub/tests/test_zipstream.py | 191 +++++++++++++++++++++++++++ 1 file changed, 191 insertions(+) create mode 100644 packages/meshbay-hub/tests/test_zipstream.py (limited to 'packages/meshbay-hub/tests/test_zipstream.py') diff --git a/packages/meshbay-hub/tests/test_zipstream.py b/packages/meshbay-hub/tests/test_zipstream.py new file mode 100644 index 0000000..51a42d0 --- /dev/null +++ b/packages/meshbay-hub/tests/test_zipstream.py @@ -0,0 +1,191 @@ +""" +The browser's ZIP writer, read back by Python's zipfile. + +A directory download is assembled in the browser: the node has no idea an +archive is being made, so nothing on this side would notice if the bytes were +malformed. These tests run the real module under Node, hand the output to +zipfile, and check that what comes out is what went in — including the CRCs, +which is the field a streaming writer is most likely to get wrong, since it is +written after the data it describes. +""" + +import io +import json +import shutil +import subprocess +import zipfile +from pathlib import Path + +import pytest + +STATIC = Path(__file__).resolve().parents[1] / "src" / "meshbay_hub" / "static" +ZIPSTREAM = STATIC / "zipstream.js" + +pytestmark = pytest.mark.skipif( + shutil.which("node") is None or not ZIPSTREAM.exists(), + reason="node or the SPA sources are not available") + + +def _build(files, force_zip64=False, tmp_path=None): + """Run zipstream.js over `files` ({name: bytes}) and return the archive.""" + # Copied with an .mjs suffix: the browser loads this file with + #