Atlas dev <-> prod data sync

Keeps the library database and settings in sync between a production install of Atlas and a dev build run from source (npm run dev). This folder is deliberately outside the Atlas repository so the script is never committed.

Files

File	Purpose
sync-data.ps1	The sync script (PowerShell).
config.json	The two data-directory paths. Edit if a path moves.
README.md	This file.

The two databases

Atlas keeps its data in a data folder whose location depends on the build:

• Production (packaged, Windows): beside the executable, C:\Users\%USER%\Applications\Games\Atlas\data (electron/main.js resolveAppDataRoot, electron/dataLocation.js).
• Dev (npm run dev): P:\dev\projects\collab\Atlas\electron\data (process.defaultApp → data root is the electron folder).

Both hold the same layout: data.db (+ -wal/-shm), config.ini, accounts.json, templates\, plus images\, updates\, extension\, logs\.

What the script syncs

Copying DB + settings only:

• data.db, data.db-wal, data.db-shm — the library
• config.ini, config.ini.bak — settings
• templates\ — banner layouts and themes

Never copied (by design): accounts.json (per-executable encryption — see Accounts), images\ (artwork, re-downloads, can be many GB), updates\ (installers), extension\ (regenerated each launch), logs\, chrome\.

Usage

From PowerShell:

# Seed the dev build with your real library/settings  (prod -> dev)
.\sync-data.ps1 -Direction ToDev

# First time only: log in to F95 / LewdCorner inside dev (Settings -> Accounts).
# That login is dev-only and persists across future syncs.

# Preview without changing anything
.\sync-data.ps1 -Direction ToDev -DryRun

# Push changes made in dev back to prod  (dev -> prod)
.\sync-data.ps1 -Direction ToProd

# Skip the "is Atlas running?" check
.\sync-data.ps1 -Direction ToProd -Force

Accounts

F95zone / LewdCorner logins are per-build. Because account secrets are encrypted against the executable that wrote them, accounts.json is never copied in either direction:

• Prod and dev each keep their own login. Log in once per site inside each build (Settings → Accounts). A login made in dev only ever affects dev.
• ToDev removes a stale prod-bound copy. If dev's accounts.json is byte-identical to prod's — i.e. left over from an old sync that still copied it — it is deleted, because dev could never decrypt it and would otherwise show "connected" while download links fail. After that, dev shows "not connected" until you log in once in dev.
• Reverse sync never touches accounts. ToProd leaves prod's accounts.json alone, so your prod login can never be broken by a dev sync.
• Sessions still expire per build. Re-login in the build whose session lapsed. Browser-method accounts store no password, so they cannot refresh themselves in any build.

Safety and rollback

• Both apps must be closed during a sync. The database runs in WAL mode; copying a live database can corrupt it. The script refuses to run while it detects Atlas.exe or electron.exe (use -Force to override).
• A timestamped backup of the destination is created first, as a sibling folder named <data dir>-sync-backup-<timestamp>. To roll back, copy that folder's contents back into the data dir and remove the -wal/-shm files there first.
• Stale WAL files are handled. When data.db is replaced, the old -shm/-wal pair is deleted before the new pair is copied in, so a leftover WAL can never be replayed into the new database.

Notes

• accounts.json is deliberately excluded from the sync because it is not portable between builds — see Accounts.
• The DB schema only ever gains columns and is migrated in place on open, so a dev-copied database stays readable by prod and vice-versa.
• The copy is a snapshot, not a live mirror. Re-run the script each time you want the two to agree.
• Dev and prod use different single-instance locks, so both apps can be open at once. That is exactly the case the running-process check protects against.