Gstore 0.1.0

24 October 2026 · previous release 0.0.4, 19 October 2026

This release is almost entirely about moving bytes: transfers now run several chunks at a time, an interrupted transfer resumes in both directions instead of only one, and a dropped connection no longer ends a transfer. There are also Linux builds for the first time, and the app now tells you when a newer version exists.

• Transfers are several times faster
• Interrupted transfers resume
• Reliability
• Knowing what it is doing
• Memory
• Linux builds
• Update notices
• Upgrading
• Known limitations
• Under the hood

Transfers are several times faster

Chunks used to be sent and fetched one at a time. A single connection to Google is limited far below what a modern link can carry — latency and per-connection limits, not bandwidth — so most of the available capacity sat unused. Gstore now runs several chunks concurrently in both directions.

Both figures come from real transfers against Google Drive on one 5G connection rated 80 Mb/s — the download at 8 streams, the upload at 4. They are a single machine on a single link, not a benchmark suite: a wired connection with lower latency will see less benefit, because there was less being wasted to begin with. A 20 GB download that had been projected at about four and a half hours finished in 96 minutes.

Four concurrent chunks is the default. That is deliberately short of what the link can take, because every stream spends Google Drive API quota and shares a per-user rate limit. Raise it if your quota budget allows:

GSTORE_DOWNLOAD_STREAMS=8
GSTORE_UPLOAD_STREAMS=8

Interrupted transfers resume

Downloads

In 0.0.4 a chunked download that failed for any reason deleted its output and started over. One timed-out chunk — number 400 of 409, say — discarded nineteen gigabytes of finished work.

Output is now accumulated in a .gstore-part file beside the destination and renamed into place only after the whole-file checksum passes, so the destination never holds partial or unverified data. Which chunks arrived is recorded, so the next attempt fetches only what is missing. Choose the same destination again and it carries on.

Uploads

Upload resume existed but reported every resumed chunk as being the size of the entire file, which made the progress bar wrong and wrote bad sizes into the index. Stored data was never at risk — reassembly uses the real bytes and verifies them — but the bookkeeping was wrong, and it is fixed.

The whole-file checksum is also cached now. Hashing a 20 GB file takes minutes, and it used to be repeated on every retry; a resumed upload skips it entirely.

Reliability

A dropped connection no longer ends a transfer

Retries previously covered rate limits and server errors, but not the most common failure of all: the network going away. A timeout or a reset connection ended the whole transfer. Transport errors now retry with the same exponential backoff, so a brief blip recovers on its own.

Cancelling, and quitting

Transfers can be cancelled, and cancelling is a pause — what has already moved is kept, and repeating the transfer continues from there.

Quitting during a transfer previously destroyed a running thread and aborted the process. Gstore now asks whether to pause and quit, and stops cleanly.

Guards against bad data

• A file truncated or shrunk mid-upload is refused rather than silently uploading a short chunk nobody notices until download time.
• A download that cannot fit on the destination disk is refused before anything is fetched, counting only what is left to fetch so a nearly-complete resume is not turned away.
• A part file that does not line up with a chunk boundary is discarded rather than being built on.

Knowing what it is doing

The transfer line now reads, for example:

Downloaded 212 of 409 chunks… 52% · 10.4 GB of 20.0 GB · 3.1 MB/s · 52m left

Percentage, byte counts, current speed and an estimate, plus how many chunks are done. The speed is measured over a trailing window, so it reflects what the connection is doing now rather than an average dragged around by an early slow patch, and a resumed transfer is not credited with work a previous run did.

On macOS the percentage had never been visible at all: the native Qt style paints a progress bar's fill but never its text, whatever the widget reports. It now lives in the label beside the bar, where it renders everywhere.

A log file

Gstore had no logging. A failed 20 GB download reported only timed out, naming neither the chunk nor how far it had got. There is now a rotating log beside the index:

macOS   ~/Library/Application Support/Gstore/gstore.log
Linux   ~/.local/share/Gstore/gstore.log
Windows %LOCALAPPDATA%\Gstore\gstore.log

Failures name the chunk, the account and the error.

Memory

Each chunk used to be read whole and then copied into a buffer — about 100 MB resident per chunk, to move data that is only ever sent 5 MB at a time. Chunks are now streamed straight from the file. Measured on a 50 MB chunk, peak memory fell from 152 MB to 62 MB, most of the remainder being the Python interpreter itself.

Downloads write directly into the output file at each chunk's offset, so a 20 GB download occupies 20 GB on disk, not 40, and finishing is a rename rather than a copy.

Linux builds

Linux users previously had only a source checkout, which cannot sign in because the bundled OAuth client is not in the repository. There is now a tarball carrying its own Qt, so it runs on any reasonably current distribution:

tar -xzf Gstore-linux-x64.tar.gz
./Gstore/Gstore

Update notices

Gstore is distributed as a direct download rather than through an app store, so nothing told you when a new version appeared. At startup it now asks GitHub's public releases endpoint whether a newer version exists and, if so, shows a strip above the tabs offering the release notes and the download page.

Nothing is downloaded or installed automatically; the buttons only open your browser. The request carries no account information, no file names, no email address, no tokens and no identifier of any kind. It is the only request Gstore makes to anywhere other than Google, it is described in the privacy policy, and it can be switched off:

GSTORE_NO_UPDATE_CHECK=1

… or by creating a file named update_check.disabled in Gstore's application-data directory. With it off, the app contacts nothing but Google.

Upgrading

Nothing to do beyond installing the new build. The local index migrates itself on first launch, linked accounts and indexed files are untouched, and a part-finished transfer from 0.0.4 is picked up rather than discarded.

These builds are not code-signed, so the first launch warns you. On macOS, open System Settings → Privacy & Security and choose Open Anyway. On Windows, SmartScreen offers More info → Run anyway.

Known limitations

• No code signing or notarization. Every platform warns on first launch.
• The Intel macOS build is best-effort. Those runners are often unschedulable, and the release ships without that asset when one is not available. Apple Silicon and Intel builds are not interchangeable.
• A chunk needs one account with room for the whole chunk. Pooled free space spread thinly across many accounts will not place a file, even when the total would fit.
• A fresh chunked upload reads the file twice — once to checksum it, once to send it. Resumed uploads skip the first pass; fresh ones do not yet.
• Uploads benefit less from concurrency than downloads (2.5× against 4.3×), and that figure comes from a 48 MB sample rather than a long transfer.

Under the hood

• The test suite grew from 52 tests to 190, with the chunked-upload and chunked-download paths covered for the first time.
• The index schema is at version 9; migrations run automatically.
• Positional file I/O goes through a small portability layer, because the syscalls that make concurrent transfers safe on macOS and Linux do not exist on Windows.