The settings, the prefixes and the logs move after the rename has been fixed.

See more details at : https://github.com/pdulvp/pmane-sa/issues/6

• an install made before the organisation became pdulvp keeps its desktop and

its wine prefixes: ~/.config/pmane-sa/pmane-sa, ~/.local/share/... and
~/.cache/... are moved under pdulvp/ on the first run, Qt knowing nothing
of a previous name

• a destination holding no file is moved into, the empty prefixes and

launches the new program makes for itself not counting as in use; one
holding files is left alone and said so, rather than two sets of prefixes
being merged behind anyone's back

• a folder named with --configPath is left alone, and a move that fails --

two filesystems, typically -- leaves everything where it was for the next run

The settings folder moves itself after the rename of the organisation

_{2026-10-30-1249-the-settings-folder-moves-itself-after-the-rename.md — 2026-10-30 12:49}

The settings used to be kept under ~/.config/pmane-sa/, the organisation name
being the program's own. It is pdulvp now, so QStandardPaths points at
~/.config/pdulvp/, and an existing install finds nothing there: Qt knows
nothing of a previous name. The program moves the old folder itself, once, at
startup.

Decisions

• Moved, not copied. A rename within ~/.config is atomic and leaves

nothing behind to diverge from. A failed rename leaves everything as it was
and the program carries on with an empty desktop rather than refusing to
start.

• Only into an empty place. The move happens only when the new folder does

not exist or holds nothing, so a desktop already in use is never written
over -- which is what a machine that ran the old installed program after the
rename looks like: the old folder is an empty desktop it made for itself.

• pmane-sa.conf too, which sits beside the folder rather than in it, and

only when there is no new one.

• Nothing is removed, except the old ~/.config/pmane-sa itself when the

move leaves it empty. Anything else in there belongs to someone else.

• Not when --configPath is given: that names a folder outright, and the

screenshots desktop in docs/ has nothing to do with the old location.

Steps

• [x] 1. src/LegacyConfig.{h,cpp}: migrateLegacyConfigFolder() -- the old

<config>/pmane-sa/pmane-sa folder and <config>/pmane-sa/pmane-sa.conf
file, renamed to the current AppConfigLocation and its .conf, the old
parent removed when empty.

• [x] 2. CMakeLists.txt: the two files.
• [x] 3. src/main.cpp: called once the names are set and --configPath is

known, before the window reads anything.

• [x] 4. Checked against three homes of its own, the program run offscreen in

each: an old layout moves, folder and .conf together; a new folder
already holding a desktop is left alone and the old one stays where it
is; a second run moves nothing and leaves no old folder behind.

• [x] 5. README: a line saying where the settings used to live.

The data and the cache move with the settings

_{2026-10-30-1448-the-data-and-the-cache-move-with-the-settings.md — 2026-10-30 14:48}

The move written for ~/.config leaves the other two behind: the wine prefixes
under ~/.local/share/pmane-sa/pmane-sa, which are the heaviest thing the
program owns, and the launch logs under ~/.cache/pmane-sa/pmane-sa. All three
are <root>/<organisation>/<application> and move the same way.

Decisions

• One rule for the three roots, config, data and cache, rather than one

written for each: the old folder is <root>/pmane-sa/pmane-sa and the new
one is whatever QStandardPaths gives now.

• The destination counts as free when it holds no file. Running the new

program once makes empty prefixes and launches folders, which must not
be what stops a 1.4 GB prefix folder from moving. Such a destination is
removed -- it can only be empty folders -- and the old one renamed over it.

• A folder holding files is never merged into. Two sets of prefixes are

not reconciled; the old one is left where it is and said so, once.

• The cache moves as well, rather than being deleted or left to rot: it is

the same shape, and a log already written is still worth reading. It is the
one root that says nothing when the destination is in use, since that would
be said at every startup for what is only logs of past launches.

Steps

• [x] 1. src/LegacyConfig.{h,cpp} renamed src/LegacyPaths.{h,cpp}, the

function migrateLegacyFolders(): the three roots in a loop, plus
pmane-sa.conf beside the config one.

• [x] 2. CMakeLists.txt and src/main.cpp follow the rename.
• [x] 3. Checked against homes of its own, the program run offscreen in each:

settings, a prefix and a log all move, over the empty prefixes and
launches the new program had already made; a data folder holding
prefixes is left alone, with one line saying so and nothing swapped; a
second run says nothing and the old roots are gone. A cache already in
use says nothing at all.

• [x] 4. README: the line about the old location covers all three.

_{Filed by prel from the completed plans at commit time.}