It's probably debatable what should happen when a GKeyfileSettingsBackend sees its keyfile suddenly disappear, but the current behavior isn't working for me, and I can't think of any other use cases nor workarounds for my use case.

The problem:

GKeyfileSettingsBackend places a file monitor on its keyfile and reloads the file any time the file monitor trips, regardless of the event.  In the event of a file deletion, all the keys suddenly reset back to their default values.  If any of those keys have been bound to GObject properties, that's most likely going to trigger "notify" signal emissions.  The signal emissions will make the backend think there's changes to be written, and it will immediately recreate the deleted key file with default values.

Why that's a problem:

In my account management redesign for Evolution, data sources (that is, calendars, address books, mail accounts, etc.) are represented by key files in a special directory which is monitored for file deletions and creations.  Deleting a data source is implemented by simply deleting the corresponding keyfile.  Evolution and the D-Bus services will each see the file deletion and take appropriate cleanup actions.  So when I delete a keyfile I want it to stay gone, at least long enough for the application to react first.

Proposed solution:

GKeyfileSettingsBackend should ignore the file deletion event so its GKeyFile remains in tact.  The file will be recreated from the GKeyFile if further changes are applied.  This will give applications a chance to react to the file deletion before the backend recreates it.