~/.config/moho is Electrons own userData directory for the app — it is live, not a leftover from the chatd era the migration was written for. It holds Electron state and exists on any normal install.
Today the migration is inert because ~/.config/nobilis also exists and the code skips when the destination is present. The hazard is that this is the only thing preventing it. Any time the data dir is absent, the daemon moves the apps config directory into it:
a --data-dir pointing somewhere new
daemon state cleared or restored without the app state
a fresh daemon dir on an install that still has the Electron one
Hit live while setting up an isolated daemon for the valgrind pass: an empty scratch --data-dir would have renamed ~/.config/moho into the scratch directory. It only did not because the directory was pre-created deliberately.
The migration is also years past its purpose. Options, roughly in order of preference:
drop the config half of the migration entirely — it has had every opportunity to run by now
gate it on the source actually looking like old daemon state (e.g. containing accounts.toml) rather than merely existing
refuse to migrate when the source is a directory another process is using
Worth doing something here because the failure mode is silent and the payload is irreplaceable — account credentials and the Matrix crypto store, per the functions own doc comment.
`migrate_from_moho_dirs` in `src/main.rs` renames `~/.config/moho` to the data dir when the data dir does not yet exist:
```rust
("config", home.join(".config").join("moho"), data_dir.to_path_buf()),
```
`~/.config/moho` is **Electrons own userData directory** for the app — it is live, not a leftover from the `chatd` era the migration was written for. It holds Electron state and exists on any normal install.
Today the migration is inert because `~/.config/nobilis` also exists and the code skips when the destination is present. The hazard is that this is the only thing preventing it. Any time the data dir is absent, the daemon moves the apps config directory into it:
- a `--data-dir` pointing somewhere new
- daemon state cleared or restored without the app state
- a fresh daemon dir on an install that still has the Electron one
Hit live while setting up an isolated daemon for the valgrind pass: an empty scratch `--data-dir` would have renamed `~/.config/moho` into the scratch directory. It only did not because the directory was pre-created deliberately.
The migration is also years past its purpose. Options, roughly in order of preference:
1. drop the config half of the migration entirely — it has had every opportunity to run by now
2. gate it on the source actually looking like old daemon state (e.g. containing `accounts.toml`) rather than merely existing
3. refuse to migrate when the source is a directory another process is using
Worth doing something here because the failure mode is silent and the payload is irreplaceable — account credentials and the Matrix crypto store, per the functions own doc comment.
Option 1: the config half is dropped. The cache half stays, because Electron keeps its cache inside userData rather than in ~/.cache/moho, so that path really is the old daemon's.
I tried option 2 first and it does not hold. Gating on accounts.toml would stop the migration firing on a clean install, but on the one machine that would still have old daemon state at ~/.config/moho, the old daemon's files and Electron's are in the same directory - the old daemon wrote to the path Electron now uses. A rename takes both or neither, so the marker makes it safe to skip and never safe to run.
Confirmed on this machine while fixing it: ~/.config/moho holds blob_storage, Cache, Code Cache, Cookies, Crashpad; ~/.config/nobilis holds accounts.toml, matrix-crypto/ and the rest. Two different applications' state, one path.
Anyone who does still have daemon state at the old path keeps it - nothing here deletes anything, and accounts.toml and matrix-crypto/ can be moved across by hand.
The list of directories to move is now its own function, so the fix is asserted as an absence: no migration may ever name a source under .config. That is testable without renaming anything in a real home directory.
Finished in [`9e885a4`](https://git.salastil.com/Salastil/nobilis/commit/9e885a4), carried into moho by [`3e746cf`](https://git.salastil.com/Salastil/moho/commit/3e746cf).
Option 1: the config half is dropped. The cache half stays, because Electron keeps its cache inside userData rather than in `~/.cache/moho`, so that path really is the old daemon's.
I tried option 2 first and it does not hold. Gating on `accounts.toml` would stop the migration firing on a *clean* install, but on the one machine that would still have old daemon state at `~/.config/moho`, the old daemon's files and Electron's are in the **same directory** - the old daemon wrote to the path Electron now uses. A rename takes both or neither, so the marker makes it safe to skip and never safe to run.
Confirmed on this machine while fixing it: `~/.config/moho` holds `blob_storage`, `Cache`, `Code Cache`, `Cookies`, `Crashpad`; `~/.config/nobilis` holds `accounts.toml`, `matrix-crypto/` and the rest. Two different applications' state, one path.
Anyone who does still have daemon state at the old path keeps it - nothing here deletes anything, and `accounts.toml` and `matrix-crypto/` can be moved across by hand.
The list of directories to move is now its own function, so the fix is asserted as an absence: no migration may ever name a source under `.config`. That is testable without renaming anything in a real home directory.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
migrate_from_moho_dirsinsrc/main.rsrenames~/.config/mohoto the data dir when the data dir does not yet exist:~/.config/mohois Electrons own userData directory for the app — it is live, not a leftover from thechatdera the migration was written for. It holds Electron state and exists on any normal install.Today the migration is inert because
~/.config/nobilisalso exists and the code skips when the destination is present. The hazard is that this is the only thing preventing it. Any time the data dir is absent, the daemon moves the apps config directory into it:--data-dirpointing somewhere newHit live while setting up an isolated daemon for the valgrind pass: an empty scratch
--data-dirwould have renamed~/.config/mohointo the scratch directory. It only did not because the directory was pre-created deliberately.The migration is also years past its purpose. Options, roughly in order of preference:
accounts.toml) rather than merely existingWorth doing something here because the failure mode is silent and the payload is irreplaceable — account credentials and the Matrix crypto store, per the functions own doc comment.
Finished in
9e885a4, carried into moho by3e746cf.Option 1: the config half is dropped. The cache half stays, because Electron keeps its cache inside userData rather than in
~/.cache/moho, so that path really is the old daemon's.I tried option 2 first and it does not hold. Gating on
accounts.tomlwould stop the migration firing on a clean install, but on the one machine that would still have old daemon state at~/.config/moho, the old daemon's files and Electron's are in the same directory - the old daemon wrote to the path Electron now uses. A rename takes both or neither, so the marker makes it safe to skip and never safe to run.Confirmed on this machine while fixing it:
~/.config/mohoholdsblob_storage,Cache,Code Cache,Cookies,Crashpad;~/.config/nobilisholdsaccounts.toml,matrix-crypto/and the rest. Two different applications' state, one path.Anyone who does still have daemon state at the old path keeps it - nothing here deletes anything, and
accounts.tomlandmatrix-crypto/can be moved across by hand.The list of directories to move is now its own function, so the fix is asserted as an absence: no migration may ever name a source under
.config. That is testable without renaming anything in a real home directory.