Storing data in workshop folder can cause data loss on update

[uniflare]

I had an issue recently where we had to update the mod via SteamCMD.
It seems that it cleared the folder, luckily I had backups :D.

I wonder, if there is a way to store data in the currently server profile folder (can we get this in SQF maybe?).
This way server owners could switch server profiles for different instances and each will have their own storage data.

[Sparker95]

That's a weird situation. Long time ago I discussed it with a person from an arma dedicated server hosting company and he said it's best to store saved games in workshop folder as it's easiest for migration, and in my experience steam never erased those files. I am not sure about SteamCMD though, maybe it's not same there? Does it always erase all contents of a mod folder?

I wonder, if there is a way to store data in the currently server profile folder (can we get this in SQF maybe?).

No, there is no such option atm, but it makes sense.

can we get this in SQF maybe?

I am not sure why such an option should involve SQF. I'd just implement it as some config file :)

[uniflare]

That must have been due to their own migration scripts - it kind of makes sense to keep all mod files in the mod, but since the generated files are per instance/users it should probably live with the other profile data.

I am not sure of the exact causes, but I know that it did happen on the server when triggering a manual update/download of a workshop mod via SteamCMD.

For Clients probably not an issue unless they unsubscribe :D.

The profile name could be taken from the executable command line if it is specified, if it wasn't, then I am unsure if there is a deterministic way to find the profile folder without scanning game memory, however that could easily break with Arma version updates.

However this would be a breaking change ofcourse, if this was implemented, a deprecation strategy should be in place maybe.

[uniflare]

FYI

Initial implementation of profile folder storage and log file location:
uniflare@393a991

Only tested on Windows with -profiles and -name switches defined.

[Sparker95]

Ohh that looks like quite a big change.
Sadly I don't have much capability now to support this little extension :( So I'd prefer to stay away from big changes for now. So, I see you can read CLI arguments in a dll. Maybe we could just read path to desired FileXT storage location from CLI without any advanced profile folder detection?

[uniflare]

Could do, however I see a potential caveat:

1. Tools that automate command-line building might need updating (eg, FASTER) to allow adding custom arguments.

Also 90% of the logic here is actually getting these arguments, so you wouldn't be saving so much of the complexity.

The current method is to save storage in the mod folder, which will cross over between profiles anyway.
A less complex way would be to simply store the data in a custom user data folder, eg on Windows, in %LOCALAPPDATA%/FileXTStorage or something. That would not be per server profile, but at least per machine account.
Alternatively again, it could go into the ProgramData folder, which would be machine-wide (as it is now).

There are many options, this is just one of them.
It is a fair chunk of code, but imo the mentioned change would be the most logical choice for a user - however it is untested on Linux and the other command line variations of specifying -name/-profiles or not.

--

Either way, I don't expect any development, and am grateful you managed to find time to interact on these matters. So no pressure from me at least ;).

[Sparker95]

Yeah I think you are right on this! However how can we switch between profile-storage and old storage in mod folder? If we were to add this feature, I'd like the plugin to still read saved game files from the old folder by default. Or what is your plan about this feature? Would you like to make a PR or do you plan to keep it for your server?

About Linux - we can declare that storage in profile folder might not on Linux, I think it is fine.

[uniflare]

I am using it on my server, and will continue to do so - it is more convenient for me :).
I can adjust the PR to include an automatic migration from old storage to profile folder. No manual configuration should be necessary and a mod update should be seamless for users.
Linux should work fine, I can adjust the PR to fall-back to old storage location if any error arises on Linux.

-- Edit, oh ofcourse it is not a PR. I just referenced a commit. This commit relies on the previous PR: #9. If that PR is merged then I can open a new PR with the changes mentioned.

[uniflare]

Updated Commit: uniflare@aac6caf

Tested compilation on Linux, however I have no time right now to setup a Linux VM and setup a dedicated server to test it thoroughly.

The commit message explains the changes, this would be my final proposal that I can turn into a PR if you request it after merging the previous PR.

This is what we are/will continue to use on our server, but I think it would be nice to provide this to other users of course :).

Thanks again for your time.