Plover config file is emptied when disk is full

[user202729]

Summary

The Plover config file is emptied when the disk is full.

Reproducing

It's necessary for the disk to be full to reproduce the issue. I think the only easier way to do this is to make a tmpfs and edit the source code to write the config file there.

Plover Version

Plover 4.0.0.dev8.

System

Arch Linux.

---

Currently, Plover truncates the file before writing to it. It's possible to write to a temporary file and move it to the original location instead.

[jladdjr]

Don't think it makes sense to plan around disks getting full. That said, I have run into this issue when plover crashes, which has happened maybe ten times in the past 3 months. I've been running the app from the *.dmg file - need to start running it from the command line so I can get some more insight into the crashes.

[user202729]

Don't think it makes sense to plan around disks getting full.

Why not? It would be better to keep the old config than to delete it (most of the time the user will not change the config anyway).

[jladdjr]

That's fair - it doesn't seem like it would hurt anything to immediately write changes to plover.cfg. I was a little surprised that wasn't the default behavior. I can't really think of a reason why you wouldn't just go ahead and do this. Maybe I'm missing something obvious.

[fourshade]

This feels like a rather rare edge case. My plover.cfg file is only 812 bytes, and I can't see it ever taking up more than a single cluster. You would have to fill up a disk down to the very last cluster in order for this bug to manifest. I'm kind of surprised that the I/O isn't effectively atomic for a file this small.

Performing writes immediately as opposed to save-on-exit would have the benefit of preserving config changes in the case of crashes. On the other hand, if a config change is what caused the crash, saving that change would mean the user is effectively locked out of Plover until he figures out what's going on and manually edits the config file. I'm not sure which behavior is preferable in the general case.

[Willem3141]

I'm not sure which behavior is preferable in the general case.

I would argue the "lose config changes on crash" behavior is way less preferable. In fact, I've often been bitten by this, not only when Plover crashes, but also because apparently for me config changes are often not saved when just rebooting my computer (which of course closes Plover as well).

I've now gotten into the habit, after making a config change or adding or removing a dictionary from the list, to manually exit and restart Plover, which is not very user-friendly 🤔

I don't think that users would really be locked out of Plover because configuration changes cause a crash. If a program suddenly starts crashing, one of my first debugging attempts would be to delete its config file anyway. This would also be an easy first debugging step for users.

[user202729]

I'm not sure which behavior is preferable in the general case.

I would argue the "lose config changes on crash" behavior is way less preferable. In fact, I've often been bitten by this, not only when Plover crashes, but also because apparently for me config changes are often not saved when just rebooting my computer (which of course closes Plover as well).

I've now gotten into the habit, after making a config change or adding or removing a dictionary from the list, to manually exit and restart Plover, which is not very user-friendly

I don't think that users would really be locked out of Plover because configuration changes cause a crash. If a program suddenly starts crashing, one of my first debugging attempts would be to delete its config file anyway. This would also be an easy first debugging step for users.

If they know where the config file is.

However, it would be possible for Plover to detect if "something is wrong" and offer to delete the config before loading it.

[mulka]

if a config change is what caused the crash, saving that change would mean the user is effectively locked out of Plover until he figures out what's going on and manually edits the config file

I'm thinking we should prevent Plover from crashing in the case of a config file change if possible. For example, if Plover can detect an invalid config file, it should say that it did so and give the user the path to the file so they can either delete it, edit it, or replace it with a different one.

If a program is crashing, one of the first things I would suggest is upgrading that program to the latest stable version. If that latest stable version can detect config files that would cause a crash, great!

Do you guys have some examples of config file problems that cause Plover to crash? Maybe we can address those individually as well.

[jladdjr]

If a program is crashing, one of the first things I would suggest is upgrading that program to the latest stable version.

agreed, believe I'm on latest stable:
4.0.0.dev8+66.g685bd33 from the *.dmg installer
... on Mac 10.15.3

(at least, that's the latest release I see shown on the github releases page)

Do you guys have some examples of config file problems that cause Plover to crash?

I don't think any of my crashes have been caused because of a config file change. Usually I'm just writing w/ Plover enabled when it crashes. It does seem that these events are correlated with strokes that involve a large number of keys being simultaneously pressed (I have some strokes for keyboard shortcuts that map to a large number of keys being mashed at the same time).

Plover hasn't been crashing on me recently. If I start seeing this again, I'll post an update with what was happening (and what I was writing) at the time of the crash.

[benoit-pierre]

Should be handled by #1123.