Is there a way to stop ASF from overwriting my config files?

[felipe19930]

Hi!

After just updating ASF from V5.0.7.0 to V5.1.1.1, I noticed this warning given by ASF:

2021-06-22 02:18:00|ArchiSteamFarm-21613|WARN|ASF|InitGlobalConfigAndLanguage() config/ASF.json config file will be migrated to the latest syntax...

Then, I opened my ASF.json and noticed that a bunch of options I previously had there, had been removed after this automatic migration. If I understand correctly, ASF removed all options that had the internal default value.

So, for example, I had Blacklist: [] in my ASF.json, but since that's the default internal value, ASF thought it was wise to automatically remove it.

I keep all my config files with all ASF's options, even when they have the default value. And that's important to me, because I when I want to try a new value for an option, I don't have to fiddle with the ASF Wiki.

So my main question actually is: How is this new behavior better than the old one, where ASF simply wouldn't touch my config files unless I explicitly requested it to? Because for me, this new behavior implies I'm not the actual "owner" of the file, since at any time ASF could decide to overwrite it.

Thank you.

[felipe19930]

I just learned about --no-config-migrate (sorry, it slipped through when I read the release notes), so forget about my previous question.

The new one actually is: Will this option be supported by ASF forever or is it just a temporary thing?

The chmod workaround mentioned in the Wiki is not that great either, because I'd have to re-add write permissions every time I needed to modify an option...

Thanks again.

[JustArchi]

I keep all my config files with all ASF's options, even when they have the default value. And that's important to me, because I when I want to try a new value for an option, I don't have to fiddle with the ASF Wiki.

And that's not doing what you intend, because if I add some new property, rename or remove existing one, then you'll have your config desynchronized with the original. I'm more than sure that by now you have several invalid props in your config.

The new one actually is: Will this option be supported by ASF forever or is it just a temporary thing?

I do not expect to remove that option, it serves a valid functionality.

The chmod workaround mentioned in the Wiki is not that great either, because I'd have to re-add write permissions every time I needed to modify an option...

There is no any chmod workaround, the read-only environment is the reason to use --no-config-migrate, not the other way around. And that is so ASF won't throw bunch of errors related to I/O write it can't do.

So my main question actually is: How is this new behavior better than the old one, where ASF simply wouldn't touch my config files unless I explicitly requested it to?

Configs are for ASF initialization, not for the desynchronized, outdated documentation that user copy-pasted 2 years ago for self-documentation, which is no longer correct anyway. ASF recommends keeping configs clean since first versions based on JSON, so more than 5 years ago, and latest ASF has a mechanism to simply do it automatically in case user didn't do that himself.

I don't see any advantage in having outdated and default props, modifying ASF configs through ASF-ui is much easier to do than manually, you'll always have up-to-date model and documentation, and the internal structure for configs and databases is up to ASF indeed, and not for the user - the user can keep his own whatever-he-wants outside of ASF config in whatever-he-wants format. Of course you can manually provide the config, since the format is open and I'm not making it impossible, I'm just saying that ASF cleans it up and doesn't change in any way what the config really does. If it's absolutely unacceptable for you, even taking all of the above into account, you have the cmd-line argument you can use, which you found out about yourself.

[felipe19930]

And that's not doing what you intend, because if I add some new property, rename or remove existing one, then you'll have your config desynchronized with the original.

Yes, but options are removed/added only on new releases. If I want to change something in between releases I'd still have to open the Wiki, whereas just by having the default option there, I could change it easily without having to open the Wiki, because thankfully, the options names are very descriptive (thank you).

I'm more than sure that by now you have several invalid props in your config.

That might be a fair assumption considering the general user base of ASF, I guess. But definitely not me. After updating from V5.0.7.0 to V5.1.1.1, I had to remove two deprecated options: IdlePriorityQueueOnly and IdleRefundableGames and add three new ones: FarmPriorityQueueOnly, SkipRefundableGames and UserInterfaceMode,

I do not expect to remove that option, it serves a valid functionality.

Thank you! 😄

Configs are for ASF initialization, not for the desynchronized, outdated documentation that user copy-pasted 2 years ago for self-documentation, which is no longer correct anyway.

I mean, is not that hard to keep your config files updated. For the most part, you just have compare yours to the one on the Wiki after a release.

I don't see any advantage in having outdated and default props, modifying ASF configs through ASF-ui is much easier to do than manually

That's very personal, though. For example, I rarely even enable IPC, e.g. when I run ASF on my phone, which is low on RAM and disabling IPC helps with that.

Additionally, I mass-edit my config files using the jq tool, which IMO is better for the amount of bots I have.

I'm just saying that ASF cleans it up

Removing or migrating deprecated options is indeed a valid cleanup and I think that's a fair feature. However, I don't consider removing default options a cleanup for the reasons I already mentioned, but it also bothers me that ASF tries to "correct" the JSON indentation of the files, which again, is totally subjective. There's no such thing as "correct indentation".

Personally, with array-based options, I like to keep the values inline rather than a value per-line, because IMO is easier to read and to quickly replace something with sed or sd.

[JustArchi]

And for those reasons, and a few another, there is --no-config-migrate which you can use, and I don't plan on removing that option because as I said it serves a valid functionality. I just have to make some call as a maintainer, and in this regard I decided that for majority of users, having this option enabled by default is better than the other way around. Of course it's impossible to satisfy everybody, and for those we have a few dozen of config properties and additional cmd switches to modify some more low-level behaviour 🙂.

[felipe19930]

Fair enough! 👌