Release v3.9.4

🚀 What's New in v3.9.4

Following our continuous efforts to bulletproof ffl for real-world environments, this release brings powerful new diagnostic tools, enhanced network resilience for unstable connections, and important platform-specific fixes.

🏥 Transfer Diagnostics Endpoint

• New /diagnosis API: If a transfer seems stuck or is experiencing network timeouts, you can now hit the /diagnosis endpoint to see exactly what's happening under the hood.
  • It provides real-time, purely technical state information (e.g., transferred volume, E2EE status, --resume state, and HTTP range details).
  • Privacy First: This endpoint strictly reports connection mechanics. Absolutely zero privacy data, file contents, or personal information is included.

⚡ Network Resilience & Edge Cases

• Taming Unstable Connections (The 68GB India Case): While ffl is designed to handle Terabyte-scale transfers effortlessly, highly unstable local networks can still introduce complex edge cases. We investigated a scenario from a user in India transferring a 68GB Blu-ray movie. Due to unstable routing to the default tunnel, the client was firing rapid, repeated download ID requests, resulting in an HTTP 499 (Client Closed Request) and 206 (Partial Content) error storm. We've optimized our connection handling and request deduplication logic to ensure the server remains stable and resilient, even when the underlying network drops and reconnects erratically.

🐛 Bug Fixes & Under the Hood

• macOS Sandbox Compatibility: Fixed a crash on macOS caused by a known Python core issue (Issue #38672). Previously, mimetypes.guess_type could throw a PermissionError when running inside restricted macOS sandbox environments. ffl now safely bypasses this limitation.
• Cleaner Logs: Cleaned up several unnecessary and noisy error logs in the terminal, providing a much cleaner output experience.
• Local Dev Privacy: Sentry error reporting is now explicitly disabled by default in local development environments to prevent dev-time exceptions from polluting production error tracking.

---

📦 Which file should I download?

• If you want a single file that runs everywhere, across OSes? choose APE (ffl.com / fflo.com).
• If you want platform-optimized size/perf, choose a native build. 🙂
• On Linux and unsure about glibc (or on musl)? -> APE ffl.com is the safest choice.

ℹ️ On the first run of a native build, the app performs an internal extraction step (by pyapp), so startup is temporarily slower once.
The install scripts pre-warm this step; manual downloads will see the one-time delay.
APE builds (ffl.com / fflo.com) are single-file and do not have this first-run warmup.

---

Windows (native)

• x86_64 → ffl-v3.9.4-x86_64-windows.zip
  Unzip to get ffl.exe.

Linux (native)

We publish two glibc baselines. Pick the highest baseline that does not exceed your system glibc:

• glibc 2.39+ — smaller & faster

  • ffl-v3.9.4-manylinux_glibc2.39-x86_64-linux.tar.gz
  • Best for newer distros (e.g., Ubuntu 24).

• glibc 2.28+ — widest compatibility

  • ffl-v3.9.4-manylinux_glibc2.28-x86_64-linux.tar.gz
  • Works on older distros (e.g., Ubuntu 20); larger due to additional internal linking.

⚠️ If your system is musl-based (e.g., Alpine) or you’re unsure about glibc, prefer APE ffl.com.

macOS (native)

• Apple Silicon (arm64) → ffl-v3.9.4-aarch-darwin.tar.gz
• Intel (x86_64) → ffl-v3.9.4-x86_64-darwin.tar.gz

The archive unpacks to a single ffl binary.

🧰 APE (cross-platform single file, zero external deps)

• ffl.com — Single-file build that runs natively on Linux, macOS, Windows, FreeBSD, OpenBSD 7.3, NetBSD, BIOS, and Android (Termux).
• fflo.com — Alternative APE build that is exactly aligned with the open-source repo (no additional/proprietary addons).
  As a result, features that require closed-source components—such as upload to server (e.g., --upload)—are not available.

For a deeper comparison between native and APE, see the README’s notes.