Repository navigation
Replies: 1 comment
|
Thanks for the feedback. The config files are saved with a delay so that changes are batched together if there are multiple API calls such that file writes are minimized. The backup/restore API calls triggered before the save event will have an issue. Will get this fixed in the next update. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hi Shreyas,
I'm setting up a fuzzing environment for Technitium DNS Server and noticed something about configuration backups.
After creating several DNS zones and adding blocked domains through the API, I immediately requested a configuration backup.
The API returned a successful response, but the backup ZIP did not contain any zone files. The "blocked.config" file also contained no blocked domains, even though the zones and blocked domains were working correctly.
Looking at the source code, it seems Technitium saves these changes to disk asynchronously, using a timer with a five-second delay. The backup API appears to read the files directly from disk, so a backup requested immediately after configuration changes may contain outdated or incomplete data.
This could be problematic when restoring a backup with "deleteExistingFiles=true", since existing zone files may be deleted even though the backup does not contain their replacements.
Is this expected behavior? Should the backup API ensure pending configuration changes are saved before creating the archive, or is there an existing API mechanism to force pending changes to be written to disk?
Thanks!
All reactions