In case of disk full condition, better questing destroys it's files

Current world (after attempt to reload):

$ ls -l betterquesting/QuestDatabase.json betterquesting/QuestProgress.json QuestLoot.json
-rw-r--r-- 1 minecraft users     442  2. Sep 17:16 betterquesting/QuestDatabase.json
-rw-r--r-- 1 minecraft users      27  2. Sep 17:16 betterquesting/QuestProgress.json
-rw-r--r-- 1 minecraft users      20  2. Sep 17:16 QuestLoot.json

Last backup:

$ ls -l betterquesting/QuestDatabase.json betterquesting/QuestProgress.json QuestLoot.json
-rw-r--r-- 1 root root  627948  2. Sep 14:02 betterquesting/QuestDatabase.json
-rw-r--r-- 1 root root  197392  2. Sep 14:02 betterquesting/QuestProgress.json
-rw-r--r-- 1 root root   18832  2. Sep 14:02 QuestLoot.json

Shall I open a second issue for QuestLoot.json to be in root and not in betterquesting/?

Can you explain a little better what's happening here and what you mean by "disk full condition"?

I guess, you had a bad day somehow. Disk full condition is, if the disk is full and no more data can be stored.

Bad day? Uhh... Okay then.

I'm not sure what you expect me to do here. If BQ literally has no disk space to work with then that's not an issue with the mod, that's an issue with your PC for you to resolve. I can't magically make more space for it to work with.

"write a new file"
Without any disk space? (or using twice as much per file) Sure.

"sync to disk"
Sync from where? RAM? Is that not just file writing?

"the old file remains unchanged"
So effectively resulting in data loss anyway... right.

And this solves what exactly?

Lets say I preemptively check available disk space (which I may add anyway). If you don't have enough space, I don't write the file. Now you've lost your new data and broke questing progression anyway. You may have stopped the file from being completely destroyed but the mod is now unable to update any data beyond that point.

The only reason I can see this happening is if a player or server operator ran their system disk dangerously close to the limit.

This is still more user error than a bug. I can prevent the mod from writing an incomplete file due to a lack of disk space but I can't fix PEBKAC when users drive their system resources into the ground expecting the application to somehow continue functioning as intended.

BQ destroying it's files that were previously written correctly is a bug in BQ. Basicly the same bug exists in ImmersiveEngineering (no response as of yet) and AdvancedRocketry (bug already addressed and fixed, needs reworking imho but that's a different story). What I expect? Write a new file (throw exception or otherwise error out if something goes wrong), sync it to disk (again, handle errors) and then rename it over the old file. In case of an error like disk full, power failure, OS crash or alien invasion, the old file remains unchanged.

"write a new file"
Without any disk space? (or using twice as much per file) Sure.

YES. If it fails, leave the old file in tact.

"sync to disk"
Sync from where? RAM? Is that not just file writing?

YES, YES, NO. If you .write() something, you write it from your process memory to OS cache. The OS writes it to disk at some later time. sync()ing makes sure, that "later time" is "now" and you only get back control AFTER the data have made it to stable storage.

"the old file remains unchanged"
So effectively resulting in data loss anyway... right.

YES, it results in keeping a valid copy with the second most current version of the data instead of loosing everything.

Lets say I preemptively check available disk space (which I may add anyway).

Multi tasking operating system. You are not the only one, who wants disk space.

You may have stopped the file from being completely destroyed but the mod is now unable to update any data beyond that point.

Yes, but the user will notice this problem and can solve it. Worst case szenario is the need to redo the last quest.

The only reason I can see this happening is if a player or server operator ran their system disk dangerously close to the limit.

I can also see a dozend different reasons, like network storage with network going down mid-write for some reason, the point is: it happens.

This is still more user error than a bug.

Blame the victim. Destroying data is ALWAYS a bug.

I can prevent the mod from writing an incomplete file due to a lack of disk space [...]

You need a solution, that works in any stage of writing with any kind of error that interrupts the writing process. Solve the problem correctly as I stated it out, as everyone is doing it for over 50 years now. The problem we're discussing here is not a subject of research for a long time now.