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

BUG: configuration file is corrupted if multiple instances of cointop are run at once. #305

Open
monomadic opened this issue Mar 2, 2022 · 2 comments

Comments

@monomadic
Copy link

I use cointop for showing price data and my portfolio totals in waybar in sway. Within a few updates, the coinfiguration file is corrupted - I'm fairly sure there's no locking on the file during write because it produces an invalid TOML file. This has a side effect of completely deleting my portfolio.

I would highly recommend splitting up this configuration file into practical use - there is absolutely NO reason whatever one would want to write a configuration file every single time you open an application. If you are doing this it suggests you should be storing something in .local/ or .cache/ instead.

Also consider storing portfolio data in a separate file (it belongs in .local actually) as this is not configuration - think of what you'd use, say, nixos or stow or a dotfiles manager for - you want to store your settings, not personal information.

Regardless, writes are highly destructive and should always be treated with care.

@lyricnz
Copy link
Collaborator

lyricnz commented Mar 2, 2022

We always try and maintain backward-compatability with the config file format. Have you got any specific example of corruption?

There are a couple of tickets to improve the state of configuration/etc #238 in particular expresses the same sentiment.

@MostHated
Copy link

Unfortunately, I have been having this issue for a while, to the point where I created a backup config, and when my script detects an error, it takes the backup config and writes it over the messed-up config to try and restore itself. It used to work pretty well, until I just recently updated to the latest version. It's got worse for some reason and is now happening within minutes of starting my scheduler (even at 20+ second intervals of attempting to query it still keeps happening) and it can't recover.

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