Currently the client stores its configuration across several files in its configuration directory by first copying the old file to *.bak and then writing the new one. This is bad because, this involves I/O on both the backup and the new file, and with the operating system or disk write cache being used, if the system crashes, both files will be corrupted by this.
It would be great if the client could:
1. Rename the configuration file, before writing the new one.
2. Flush the disk cache after or use direct I/O (i.e. writing without write caching) for every write operation on critical configuration files.
3. Keep more than just one backup (possibly a configurable amount) *.bak file
4. Check that the configuration file has been reliably written to disk
5. Enable the recovery of torrent activity configuration in <ConfigDir>\active from the original torrent file in <ConfigDir>\torrents
6. Use a more corruption resilient storage format, like redundant SQL tables in a rapid resilient configuration instead of the BEncode format files currently in use.

PS: This request is not related to the backup feature (only allows daily backups which are insufficient, and backs up everything). I am looking for better corruption and crash resilience for the files that are currently being actively used and changing by the minute or not even present in the previous days backup.
PPS: The backup feature appears broken in the latest trunk version, backups where a single file failed to copy (because it's in use and locked by the OS) aren't kept around, leaving you with no backup at all. My latest backup (runs daily) is 10 days old and I now have to fix over 150 broken torrents by hand. A working backup would at best have helped reduce that amount by half, however.