FileN

Recent Commits

• Dwynr (08 Jul 26)

  fix(rclone): authenticate the rc interface (drop --rc-no-auth) The in-repo rclone launcher started every role's remote-control server with --rc-no-auth on a fixed loopback port, exposing the full rc API unauthenticated. operations/copyurl writes attacker-controlled bytes to any local path, so a CORS-simple cross-origin POST from any web page the victim opens (no preflight, and it need not read the response) is an arbitrary local file write -> RCE: an autostart/LaunchAgent/Startup entry, or overwriting ~/.bashrc, ssh keys, etc. config/create'ing a local remote likewise yields full local filesystem read/write. Confirmed against the bundled rclone v1.74.3; the foreign Origin header is no barrier. Replace --rc-no-auth with an ephemeral, per-process HTTP Basic pair: RcloneProcess mints RCLONE_RC_USER/RCLONE_RC_PASS via generateRcCredentials() and injects them into the child env (kept out of argv and the process list); the existing RcClient presents the same pair. rclone then answers 401 to every other caller while the app's own rc calls keep working. The rc env vars fail closed (verified end-to-end), unlike serve-s3's RCLONE_AUTH_KEY (rclone#9044), so the s3 --auth-key stays on the CLI.

• Dwynr (03 Jul 26)

  fix(windows): hide the rclone watchdog console (drop detached helper) The crash-safety watchdog spawned cmd.exe /c monitor.v<N>.<role>.bat with detached: true + windowsHide: true. On Windows, DETACHED_PROCESS makes the OS ignore CREATE_NO_WINDOW (what windowsHide sets), so cmd.exe allocated its own VISIBLE console that stayed open for the whole session - the reported stray monitor.v3.drive.bat window. Drop detached on the Windows helper only: windowsHide then hides the console, and the helper still outlives the app for its crash cleanup because Windows does not reap child processes when the parent exits (unref() keeps it off our event loop). POSIX keeps detached - it needs its own process group for the group-kill. rclone itself was already hidden (not detached + windowsHide).

• Dwynr (02 Jul 26)

  fix: reliable app quit + no duplicate instance (all platforms) macOS Dock "Quit"/Cmd+Q left the process alive but window-less for up to 60s, and a relaunch during that limbo spawned a second instance (two windows, two tray icons). Root cause: the will-quit handler preventDefault()'d the quit and ran an async teardown with an untimed worker.stop() and a 60s ceiling, while nothing stopped activate/second-instance from resurrecting the app mid teardown. - will-quit: drop the worker.stop() wait (the worker is an in-process worker_threads thread that dies with the process anyway), keep the already-bounded rclone.killAll() (flush + clean-unmount), cap at 15s, always app.exit. - Guard reactivation while quitting: activate / second-instance / showOrOpenDriveWindow no-op once shouldExitOnQuit is set. - Route every explicit-quit entry point through the graceful path: window-all-closed, tray "Exit" and restart now use app.quit() instead of a hard app.exit that skipped teardown (stale mount / relaunch collision on Windows/Linux). - watchdog: SIGTERM-before-SIGKILL on POSIX so crashes also flush rclone's write-back cache (monitor script version bumped to 3).

• Dwynr (02 Jul 26)

  fix(ci): build macOS on macos-26 with setup-xcode for the .icon Xcode 26's actool (the Icon Composer .icon compiler) crashes on the macos-15 runner: it links macOS-26-era CoreMedia/MediaToolbox/AVFCore symbols that are absent on macOS 15 (dyld sets them to 0xBAD4007), cascading into an AssetCatalogAgent crash. Run the mac job on macos-26 (Tahoe), whose native frameworks match Xcode 26, and pick Xcode with maxim-lobanov/setup-xcode (latest-stable -> the 26.x that matches the local build). Replaces the macos-15 + ad-hoc xcode-select workaround.

• Dwynr (02 Jul 26)

  fix(ci): select Xcode 26 on mac runner for Icon Composer .icon electron-builder compiles mac.icon (build/icons/mac/icon.icon) with actool, which must be >= 26 for the .icon format. The macos runner ships Xcode 26 but defaults to 16.4, so the build failed: "Unsupported actool version ... found 16.4". Pin the runner to macos-15 (which includes Xcode 26) and xcode-select the newest installed Xcode 26 before the build step.

• Dwynr (02 Jul 26)

  fix(ci): pass explicit tag_name to action-gh-release softprops/action-gh-release derives the release tag solely from the run's GITHUB_REF; with no tag_name input it throws "GitHub Releases requires a tag" whenever that ref isn't refs/tags/*. Pin the tag from the release payload (github.event.release.tag_name) on all three build jobs so attaching artifacts never depends on ref inference.

• Dwynr (02 Jul 26)

  fix: refine mac icon glass and lighting settings Update `build/icons/mac/icon.icon/icon.json` to add appearance-specific blur, fill, glass, and translucency specializations, enable combined lighting/specular effects, and slightly reduce the logo scale. This aligns icon rendering behavior across light/dark/tinted appearances.

• Dwynr (02 Jul 26)

  chore(icons): adopt macOS 26 Icon Composer .icon + drop unused icon assets macOS icon: - mac.icon now points at build/icons/mac/icon.icon (Icon Composer). electron-builder derives BOTH the modern Assets.car (CFBundleIconName; macOS 26 light/dark/tinted/clear appearances) and the legacy icon.icns (CFBundleIconFile; older macOS) from it, so old macs keep working - no separate legacy file to maintain. - Removed the runtime app.dock.setIcon() on macOS (status.ts) and the stale assets/icons/app/darwin.icns: a runtime setIcon overrode the bundle icon with a flat image and lost the appearance variants. The dock/Finder icon now comes from the bundle. - afterPack fails the mac build if Assets.car or icon.icns didn't compile (e.g. Xcode 26 missing) instead of silently shipping the default Electron icon. Dropped 31 unused icon files - referenced nowhere in src/ (verified against src/assets/index.ts, the only loader; dynamic paths are ${platform}.ext, overlay/0.png, and the hardcoded tray/*@2x.png names): - app/*Notification.{icns,png,ico} - getAppIcon never loads the notification variants - app/overlay/{1..9,99}.png - getOverlayIcon always returns overlay/0.png - tray/{dark,light}/** - a theme-adaptive tray that was never wired up Windows/Linux runtime icons, the tray @2x set, overlay/0.png, and the build win/png icon sets are unchanged.

• Dwynr (02 Jul 26)

  fix: inject minimumSystemVersion after electron-builder writes latest-mac.yml The gate in the previous commit was a silent no-op. It injected minimumSystemVersion from the afterAllArtifactBuild hook, but electron-builder writes latest-mac.yml AFTER that hook runs (the hook fires inside packager.build().then(); the yml is written later in publishManager.awaitTasks -> writeUpdateInfoFiles). So the hook scanned an empty prod/, matched no *-mac.yml, and did nothing - the published yml would ship WITHOUT minimumSystemVersion and Big Sur clients would still be offered the Electron 43 build that cannot launch. (The earlier local check passed only because it ran against a hand-made yml, never a real build - caught by an independent fact-check.) Move the injection to a standalone post-electron-builder step (build/inject-min-darwin.js) chained into build:mac after electron-builder exits, when latest-mac.yml exists. It now FAILS LOUDLY (exit 1) if no *-mac.yml is found, so this can't silently regress again. Verified against the REAL pipeline: the key lands in prod/latest-mac.yml and survives the later build:hashes step's YAML round-trip. Reverts the afterAllArtifactBuild hook to DMG-notarization-only.

• Dwynr (02 Jul 26)

  chore: bump Electron to 43 + gate the macOS auto-update to macOS 12+ Electron 42 -> 43. Verified our main-process API surface compiles clean against 43's types and touches none of the APIs removed/changed across 34->43 (only showHiddenFiles in a Linux dialog, which is ignored, not an error). Electron 38+ requires macOS 12 (Chromium dropped macOS 11 / Big Sur), so the 34-built installed base can include Big Sur users who cannot run this build. electron-builder writes minimumSystemVersion only into the Info.plist, not into latest-mac.yml, so electron-updater would still offer the update to those clients and they'd install a build that won't launch. Fix, two layers: - mac.minimumSystemVersion '12.0' -> Info.plist LSMinimumSystemVersion. - afterAllArtifactBuild injects 'minimumSystemVersion: 21.0.0' into latest-mac.yml (the DARWIN version electron-updater compares against os.release(); macOS 12 = Darwin 21), so clients on macOS 11 (Darwin 20) or older are cleanly NOT offered the update instead of being bricked. Verified injection is top-level, idempotent, preserves the sha512 entries, and leaves non-mac ymls alone.

• Dwynr (02 Jul 26)

  fix: detect macFUSE by its dylib, not a stale pkgutil receipt isMacFUSEInstalled had the same stale-receipt false-positive as the old FUSE-T check: after the dylib/kext checks it fell back to a pkgutil receipt (io.macfuse / com.github.osxfuse). A receipt outlives an uninstall, so on a machine where macFUSE was removed but its receipt remained, isMacFUSEInstalled returned true -> the network-drive dependency step skipped the FUSE-T auto-install AND passed the 'a FUSE layer is required' require-check, so rclone then failed to mount with 'cgofuse: cannot find FUSE' (identical to the FUSE-T bug). Detect macFUSE only via the libraries cgofuse actually dlopens (host_cgo.go order: /usr/local/lib/libfuse.2.dylib for v4+, then /usr/local/lib/libosxfuse.2.dylib for older) before it falls back to FUSE-T. Drop the pkgutil receipt and the macfuse.fs kext bundle: cgofuse loads the dylib not the kext, and a macFUSE whose dylib isn't at these paths is unusable by cgofuse anyway, so neither adds a usable-macFUSE detection - only false positives. The macFUSE-first / FUSE-T-fallback selection and the 'skip FUSE-T install when macFUSE is present' gating are unchanged and correct.

• Dwynr (02 Jul 26)

  fix: detect FUSE-T by its dylib, not a stale pkgutil receipt The macOS network-drive auto-install didn't fire after FUSE-T was removed: isFUSETInstalledOnMacOS() returned true from a leftover pkgutil receipt (receipts outlive an uninstall - files gone, receipt left behind), so ensureDriveDependencies skipped the install while the actual FUSE library was absent, and rclone failed with "cgofuse: cannot find FUSE". Detect FUSE-T solely by /usr/local/lib/libfuse-t.dylib - the symlink FUSE-T's pkg postinstall creates and the exact path rclone's cgofuse dlopens (fs.pathExists follows the symlink, so a dangling link whose versioned target was removed correctly reads as absent). Also read the installed version from that symlink's target (libfuse-t-<version>.dylib) instead of the receipt, so both presence and version detection are receipt-independent. Verified the fixed check returns false on a receipt-present-but-dylib-absent system.

• Dwynr (02 Jul 26)

  build: set desktopName for reliable Linux window association electron-builder warns that without desktopName in package.json, Electron's runtime app_id / WM_CLASS may not match the generated .desktop entry, so desktop environments can't link running windows to the launcher (generic/ungrouped taskbar icon). Set desktopName to "Filen.desktop" (matching the existing executableName / productName) plus linux.syncDesktopName: true. Deliberately zero-change to the generated artifact: the installed .desktop stays Filen.desktop and StartupWMClass stays Filen (both already derived from executableName/productName = "Filen"), so deb/rpm upgrades don't orphan the old entry and no WM_CLASS identity shifts. The only effect is Electron now deterministically reports WM_CLASS=Filen, matching StartupWMClass — which fixes association and silences the warning. Linux-only; Windows/macOS packaging ignores both fields.

• Dwynr (02 Jul 26)

  build: verify bundled rclone binaries on every platform in afterPack The afterPack guard was macOS-only, so a Windows/Linux build with an empty bin/rclone (e.g. a failed fetch) would build green and silently ship a broken drive. Run the presence check on ALL platforms: verify both arch binaries for the current OS exist in app.asar.unpacked/bin/rclone, throwing with a directory dump if any are missing. Signing stays macOS + Developer-ID-identity gated (skipped on unsigned builds), but presence is now always enforced.

• Dwynr (02 Jul 26)

  fix: extract rclone with native unzip/tar instead of extract-zip Root cause of the macOS CI failure: extract-zip's promise silently never settled mid-extraction on the runner (Node 24 / macOS 26), draining the event loop so the fetch process exited 0 with the zip un-extracted - a green fetch step but an empty bin/rclone, which the afterPack guard then correctly rejected. The download was fine; extraction was the hang. Replace extract-zip with the platform's native unzip (unzip on macOS/Linux, bsdtar/tar on Windows), run as a child process with a 120s timeout so any future hang becomes a loud rejection instead of a silent exit. Verified locally: both osx arches download, extract, and the extracted binary runs (rclone v1.74.3).

• Dwynr (02 Jul 26)

  ci: instrument rclone fetch + afterPack to trace the macOS packaging failure The macOS runner packages an empty bin/rclone (afterPack guard fires) even though fetch exits 0 and Windows/Linux succeed. To pinpoint whether fetch dies mid-loop, exits 0 without producing binaries, or the files don't survive to packaging, add: - fetch.mjs: a process exit/unhandledRejection/uncaughtException tracer (the exit line prints last on ANY early exit, revealing code 0 = drained vs non-zero = crashed), a post-loop assertion that both raw binaries exist (fail loudly rather than exit 0 on an incomplete fetch), and an end-of-run manifest of bin/rclone + bin/deps contents. - afterPack.js: dump the real bin/rclone + app.asar.unpacked/bin state before throwing (missing vs empty vs unexpected names). Verified locally on macOS: a full run downloads both arches, extracts both, prints the manifest, and exits 0 - so the logic is correct and the failure is runner-side.

• Dwynr (02 Jul 26)

  ci: harden rclone download stream handling Refactor `downloadToFile` to use `stream/promises` `pipeline` instead of manual pipe/event wiring so aborted or prematurely closed HTTPS downloads fail reliably (and can be retried) instead of exiting silently. The hash is now computed from the completed file via `sha256File`, and logging was added for downloaded size and extraction start to improve CI/debug visibility.

• Dwynr (02 Jul 26)

  ci: add retry/backoff for rclone fetch downloads Introduce a shared `withRetries` helper in `build/rclone/fetch.mjs` to retry flaky network operations with linear backoff. Apply it to checksum fetching and all artifact downloads (rclone zips, FUSE-T, and WinFSP) so transient CI/network hiccups don't fail the whole build while preserving strict checksum validation behavior.

• Dwynr (02 Jul 26)

  build: fail a signed macOS build that has no rclone binaries afterPack silently no-op'd when the rclone dir was missing/empty, so a dropped or mis-ordered CI fetch step could produce a signed, notarized build with no rclone binaries - an app whose network drive / S3 / WebDAV never start. Resolve the signing identity first: with no identity it's an unsigned dev build (still a no-op), but with a Developer ID identity present (a real release) and zero binaries it now throws. Also scope the codesign filter to the exact osx binary names so stray files (e.g. a leftover release zip) are never handed to codesign.

• Dwynr (02 Jul 26)

  build: fail the build on native-dependency version drift The rclone/WinFSP/FUSE-T versions are hard-coded in several files (fetch.mjs as the source of truth, plus constants.ts, index.ts and installer.nsh) with no cross-check, so a bump that misses one file would silently ship a mismatched binary or installer. Add build/rclone/check-versions.mjs, wired into `npm run build` (so it runs locally and in CI before packaging), which fails loudly if any of them disagree, or if an expected declaration can't be found at all.

• Dwynr (02 Jul 26)

  fix: apply the uniform 32 GiB VFS cache cap to the network drive The drive's --vfs-cache-max-size read networkDriveConfig.cacheSizeInGi, which the shared web config hardcodes to 10 with no UI, so the drive was capped at 10 GiB while serve s3/webdav used the intended 32 GiB (VFS_CACHE_MAX_SIZE_GI). Use the same constant for the drive so the cap is genuinely uniform across roles, and drop the vestigial cacheSizeGi option that only ever carried the stale default.

• Dwynr (02 Jul 26)

  fix: don't open the unused SDK realtime socket in the main process The sleep/wake "Uncaught Exception" fix only covered the worker. The main process still forced connectToSocket: true (ipc setConfig), so its SDK FS socket connected and — like the worker's before — had no "error" listener; a transient TLS drop on sleep/wake emits "error" with no listener and crashes the main process. Main consumes no realtime FS events (no socketEvent listener, no sdk.fs() usage; the renderer runs its own SDK/socket), so disable the socket there too, matching the worker. Also remove the worker's dead "error" listener: it was on the top-level sdk.socket, which never connects — the private FS socket is the one that emits — so it never guarded anything.

• Dwynr (02 Jul 26)

  fix: read FUSE-T version from all pkgutil receipts, not the first installedFuseTVersion() took the first /fuse-t/i receipt from `pkgutil --pkgs`, but FUSE-T's receipt ids embed the version and the installer never forgets the old receipt on upgrade, so old and new receipts coexist. Since --pkgs output is not version-sorted, the first match could be a stale older version, keeping the upgrade gate (installed < bundled) true and re-prompting for admin on every drive start even after a successful upgrade. Read every matching receipt and take the max version. Also log when the version can't be determined so a future silent skip (e.g. a renamed bundled pkg) is visible.

• Dwynr (01 Jul 26)

  feat: version-aware FUSE-T upgrade for existing macOS installs Existing FUSE-T installs never got bumped when we shipped a newer bundled version (unlike rclone, which is version-keyed in userData, and WinFSP, which the NSIS installer re-runs on every app update). Add a best-effort upgrade at drive start: when FUSE-T is the active FUSE layer (no macFUSE) and the installed pkgutil-receipt version is older than the bundled fuse-t-macos-installer-<version>.pkg, re-run the installer. Bulletproofing: - macFUSE users are never touched (only fires when FUSE-T is the layer). - Never downgrades and never reinstalls the same version. - Skips silently when the installed version can't be read (raw-dylib install with no receipt). - Non-blocking: a declined/failed elevated install is caught and logged, and the mount proceeds with the existing (older, still-working) FUSE-T; the next mount simply re-attempts. - Runs before our own mount, so it can't clobber an active Filen drive.

• Dwynr (01 Jul 26)

  feat: ship rclone as raw binaries (asarUnpack) instead of runtime-extracted zips Fixes the installed-build failure where the runtime zip extraction stalled (leaving a .extract-* dir) so rclone never started, and cleans up macOS notarization of the rclone binaries. - fetch.mjs: extract rclone from the verified zip at build time and ship it raw as bin/rclone/rclone-<os>-<arch>[.exe] (both arches per OS); the zip is discarded - package.json: bundle bin/rclone via the asar + asarUnpack (drop the per-platform rclone extraResources). This lands the binaries in app.asar.unpacked, where electron-builder signs them - Windows natively (its app.asar.unpacked signing walk), macOS via the afterPack hook - binary.ts: replace the runtime extract-zip with a plain copy of the bundled raw binary into userData/rclone/bin/<version> (chmod + verify + atomic rename); no more .extract-* dirs or runtime unzip - afterPack.js: simplified to codesign the raw rclone binaries directly (Developer ID + hardened runtime + timestamp), macOS-only; Windows/Linux handled without it - constants.ts: rcloneZipName -> rcloneBundledBinaryName; manager zipDir -> bundledDir Dev build unaffected (isDev resolves the repo bin/rclone, runs unsigned rclone). Verified locally: fetch produces runnable raw binaries, binary.ts copies + runs them, the afterPack codesign flow signs + verifies a raw binary. macOS/Windows signing + notarization to be confirmed by CI.

• Dwynr (01 Jul 26)

  fix: sign bundled rclone binaries in an afterPack hook for macOS notarization Apple notarization inspects nested archives and rejected the app because the rclone Mach-O binaries inside Resources/rclone/*.zip were not Developer-ID-signed / hardened-runtime / timestamped. electron-builder signs the app's own Mach-O but treats the zips as opaque data, so add a macOS-only afterPack hook that - before the app is sealed - extracts each rclone zip, codesigns the binary (Developer ID + --options runtime + --timestamp), and re-zips it with the layout preserved for the runtime extractor (src/lib/rclone/binary.ts). No entitlements (rclone is a standalone static Go binary). No-op on Windows/Linux and on unsigned dev builds (no Developer ID identity). Verified locally that the ditto extract -> sign -> re-zip round-trip survives the runtime extract-zip extraction and the binary still verifies + runs; the Developer ID signing + notarization itself needs the mac CI cert.

• Dwynr (01 Jul 26)

  ci: update node versions

• Dwynr (01 Jul 26)

  fix: declare + migrate to selfsigned 5.x for the rclone TLS serve tls.ts imports selfsigned to generate the loopback TLS cert for serve s3 / serve webdav, but the dependency was never declared - it only compiled/ran when incidentally present, so npm ci in CI (and a clean install / the packaged app) failed with TS2307 and would miss the module at runtime. Declare selfsigned ^5.5.0 (latest; ships its own types, so no @types/selfsigned) and migrate tls.ts to its API: generate() is now async and the `days` option was replaced by explicit notBefore/notAfter dates (validity kept at 397 days). generateServerCert is now async and its sole caller (ensureServerCert) awaits it. Verified at runtime: cert/key PEM, SANs cover 127.0.0.1/::1/localhost, 397-day validity.

• Dwynr (01 Jul 26)

  chore: bump version

• Dwynr (01 Jul 26)

  fix: disable socket connection in worker SDK Update worker SDK initialization to set `connectToSocket` to `false` instead of `true`. This prevents the background worker from opening a socket connection, avoiding unnecessary real-time socket usage in the worker process.