(Python_backup tool) Fixing a Bug Where a PyInstaller-Packaged Desktop App Resets Its Settings on Every Restart

Overview

We packaged an internal file-sync desktop utility as an exe for distribution, and ran into a case where a settings-save feature that worked fine otherwise kept resetting itself, but only in the exe build. It ran without issue when launched directly as a .py script, which made this one take a while to track down — sharing the case here.

The Problem

• Users would configure server connection info and save it after launching the program.
• After quitting and relaunching, all saved settings were gone.
• Not reproducible in the dev environment (python main.py) — only happened with the PyInstaller- built .exe.

Root Cause

When built with PyInstaller's --onefile option, the app extracts its bundled resources into an OS temp folder (e.g., a subdirectory under %TEMP%) at launch time and runs from that location.

The problem was that our settings-file save path was calculated relative to "the folder containing the currently running code file." In a normal script run, that correctly points to the folder holding the source code. But in a --onefile-bundled exe, it instead points to a temp folder that gets freshly created on every launch — and gets deleted the moment the process exits. So any settings file saved into that folder simply didn't exist the next time the app ran.

The Fix

The core fix was determining at runtime whether the code is running inside a bundled executable, and picking the base path accordingly.

On program start:
  if (running as a PyInstaller bundle):
      base_path = the folder containing the .exe itself
  else:
      base_path = the folder containing the current source file

  settings_file_path = base_path + "config.json"
  log_file_path = base_path + "app.log"

Whether the app is running as a bundle can be checked via a standard flag exposed by the Python runtime, so we could branch on it without adding any external dependency.

Retrospective

• We reconfirmed that a local script run and a packaged executable can be completely different environments from a filesystem perspective, even with "the same" code.
• Since then, we've made it a habit to always ask, when writing any path-related logic, "could this path calculation differ depending on distribution form (script vs. bundled exe)?"
• We also added "relaunch the built executable and verify settings persist" as a formal item on our pre-release checklist.