GHelper loses settings when the storage is full

[Iemand005]

Rules

• I made myself familiar with the Readme, FAQ and Troubleshooting.
• I understand that, if insufficient information or no app logs will be provided, my issue will be closed without an answer.

What's wrong?

GHelper has a tendency to lose it's configuration when used while the storage is full.

There is a backup config file but this also gets reset immediately.

This caused all my settings to disappear twice. If an error occurs saving or reading the config, the backup should not be overwritten to default too. The backup should be kept or a second backup should be made.

How to reproduce the bug?

Fill your storage and make GHelper crash.

Logs

log.txt

Device and Model

Asus ROG Flow x16

Additional information.

No response

Armoury Crate

Installed

Asus Services

None

Version

0.204

OS

Windows 11 23H2

[seerge]

@Iemand005 hello,

Do you mean that you fill all your drive so it's not writeable anymore (i.e. full too 100%?). I strongly advice to clean up some space, as it will introduce a lot of difficulties from windows and other apps as well.

As for G-Helper's config, currently it first writes config in 2 steps.

• It writes backup config
• Waits for 0.5 seconds, reads backup (to check if it was written successfully and has no errors) and if so does a file copy (windows operation) into main config

This is done intentionally, to prevent config corruption in case if app is accidentally closed or interrupted.

g-helper/app/AppConfig.cs

Line 95 in ecf10e9

var backupText = File.ReadAllText(backup);

I honestly don't know what else can I offer here :) If you use device in such extreme conditions why don't you just make a manual copy of the config somewhere else once ?

[seerge]

P.S. I don't see any notes about broken config.json in the log. When did it happen last time and why did app crash ?

[Iemand005]

I have a backup of my log from right after it happened

log.txt

I usually have free storage but sometimes opening a lot of apps or loading an LLM into memory results in a lot of paging that can easily use 10GB of storage, if I don't notice in time it happens that I'm left with 0 bytes free.

Maybe it's not even caused by the full storage, I don't know what the cause is but it has happened multiple times.

[seerge]

@Iemand005 ok,

Let's try to figure out what exactly happens to a config in that case.

Can you use this build (it will also save old broken config before erasing it) and try to reproduce the scenario ?
GHelper.zip

Thanks

[Iemand005]

Thank you!
I did some testing. I see that it checks for { and } to be present before saving the file to avoid writing invalid data to the file which is wat I was hoping it'd do. The errors in the logs were '0x00' is an invalid start of a value. Path: $ | LineNumber: 0 | BytePositionInLine: 0. and this occurred in version 0.202, the code hasn't changed in 0.204 as far as I can tell.

The error shows the config.json must have somehow ended up being 0 bytes large which usually a result of the storage being full and it failing to allocate more space after having created the file I assume. I don't see any out of storage errors in the logs when it erased my configs.

I did notice the log actaully also fail to write sometimes when the storage is full which causes the log to be cleared.

What I believe happened is:

1. The backup file was written successfully.
2. The storage got full.
3. It attemted to copy the backup which failed and config.json became 0 bytes:
   

   g-helper/app/AppConfig.cs

   Line 99 in 15db22c

   File.Copy(backup, configFile, true);

4. It tried saving again and it failed twice:

   g-helper/app/AppConfig.cs

   Line 77 in ecf10e9

   File.WriteAllText(backup, jsonString);

   
   

   g-helper/app/AppConfig.cs

   Line 84 in ecf10e9

   File.WriteAllText(backup, jsonString);

5. It tried logging it but that also failed leaving the log blank (0 bytes).
6. I realised and freed up storage.

The logs show 2 days before it attempts to read the config. What I assume happened is:

1. I didn't change GHelper settings for 2 days, so it didn't attempt to save the config now that it has space to do so.
2. I think I remember GHelper freezing up (not responding) and crashing, after reopening it the settings were reset.

I probably have screenshots and stuff from the days on which it happened, if you want I can go look for that.
This is just how I believe it happened, I'm likely wrong but to me it does look like if you're unlucky and your storage happens to fill up in that half second at

g-helper/app/AppConfig.cs

Line 93 in ecf10e9

Thread.Sleep(500);

there's a chance it can result in both config files being emptied and closing GHelper before it saves the config it has in memory would result it in reading empty files on next launch.

This could be tested by changing the 500ms pause into a 5 minute pause or so, filling up the storage manually within these 5 minutes and seeing if it results in an empty config, then change a setting to make it try to save again with the storage still full, then killing GHelper forcefully, freeing up space and restarting it.

Would you like me to test this?
If this turns out to indeed be the case I can probably fix it for you when I have the time to do so if you want.
Thank you very much!

[seerge]

@Iemand005 hello,

I think you have mixed order of actions in your interpretations :)

As mentioned above:

• it first writes a backup config
• and then in 0.5 seconds checks if backup is a valid json i.e. contains { + }
• and just runs a native-windows file copy operation that is instant and is handled by windows itself as far as I know, so this operation can't fail in the middle

This is done to ensure that if any errors / full disk / etc will happen during writing a backup - main config won't be touched.

g-helper/app/AppConfig.cs

Line 97 in ecf10e9

if (backupText.Contains("{") && backupText.Contains("}"))

In your case both configs were corrupted, which means that backup config has passed a { + } test, but was still corrupt by some reason.

Can you just run the build I linked (it will store original configs before overwriting them) - and if it happens again - upload original configs here ? I want to see what exactly was wrong with them .

I can replace a { + } check with a proper json parsing, but initially this was done to save resources.