Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Saved servers lost after quitting on macOS #238

Open
93-infinity opened this issue Nov 17, 2024 · 8 comments
Open

Saved servers lost after quitting on macOS #238

93-infinity opened this issue Nov 17, 2024 · 8 comments

Comments

@93-infinity
Copy link

Every time I quit the app, I need to re-configure the servers on next launch (everything is lost).

@qu1ck
Copy link
Member

qu1ck commented Nov 17, 2024

What is your app version and macos version?
Sounds like it crashes, otherwise settings should be saved. Can you try configuring servers and then restarting the app immediately without connecting to that server?

@WombatFromHell
Copy link

I'm seeing the same behavior on the latest AppImage of v1.4.0. I'm running the AppImage on Bazzite (Fedora 41). The settings file seems to get saved to ~/.config/trguing.json with what appears to be valid settings inside of it, but the file at that location isn't loaded when restarting the app. Once the config is made any changes in the app are never written to disk.

@qu1ck
Copy link
Member

qu1ck commented Nov 21, 2024

@WombatFromHell can you definitively confirm that config file is created and not read from the same location?
To do a clean test perform following steps:

  1. Rename/delete existing config file
  2. Launch the app, configure server, exit without connecting to the server
  3. Verify the config is created
  4. Launch the app again, with same exact method (i.e. from same terminal or from same shortcut) and check if server is still configured

If that is the case then it's very fishy and probably some bad interaction of appimage and fedora security features, I am at a loss what it could be. Try using the flatpak or compile the app yourself, the appimage is tested on debian/ubuntu only.

@WombatFromHell
Copy link

I figured out what my issue was, tauri v1.0 apps don't follow symlinks, and on Bazzite the /home directory is actually a symlink pointing at /var/home which cannot be resolved by the tauri filesystem plugin. A simple workaround is to define XDG_CONFIG_HOME pointing at the real path when using the AppImage and then the app behaves normally.

I'm unsure if what I was experiencing is also related to this issue as well, but it sounds like it's possible it could be depending on the user's environment or filesystem permissions context.

@qu1ck
Copy link
Member

qu1ck commented Nov 21, 2024

$XDG_CONFIG_HOME should be defined on any freedesktop compliant desktop env, are you using something esoteric?

@WombatFromHell
Copy link

Sort of. Bazzite is a descendant of Fedora Silverblue which is a containerized version of Fedora. Due to how rpm-ostree and Silverblue are designed the filesystem has overlays for /var and /etc that are mutable but everything under / is immutable including /home and /mnt. So in order to preserve compatibility with most linux tools /home is put inside /var and symlinked to /home. That's my best attempt to explain it, so apologies to anyone if I got some of that incorrect.

Either way, tauri v1.0 doesn't like XDG data directories behind symlinks whether it's inside or outside of an AppImage, but tauri v2.0 apparently improves that behavior to support symlinks by default from what I understand.

@qu1ck
Copy link
Member

qu1ck commented Nov 22, 2024

You can try to compile TrguiNG from tauriv2 branch to test your theory. It has some issues if you are on wayland but should be fine to use otherwise.

@WombatFromHell
Copy link

Compiling the tauriv2 branch and using the subsequent AppImage does in fact fix my issue without needing to override XDG_CONFIG_HOME. Theory confirmed I suppose.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants