[Bug Report] Manipulating cache settings causes an error to log.

[GTHK]

[2008-08-21 00:02:08] Settings integrity check failed (duplicate keys: 1 count: 1), repaired: C:\Documents and Settings\[Cake]\Application Data\uTorrent\settings.dat

I can produce this by doing the following on build 11903:

0. Preferences > Advanced > Disk Cache

1. Enable the cache size override (or disable and re-enable). > Apply

2. Disable the cache size override. > Apply

-Alternatively-

1. Enable the cache size override. > Apply

2. Change the specified size. > Apply

That's all there is to it, the only problem is it is specific to my settings.dat. I tried to narrow it down to one key but instead I simply altered the behavior to only giving the message twice. If I use Ultimas bencode editor and delete keys .fileguard to extras it stops the issue entirely.

http://www.mediafire.com/?nbm0wep2jic

[Ultima]

Yep, I also noticed/reported the issue to alus yesterday with a settings.dat file as well.

The problem doesn't lie specifically with disk cache settings -- I managed to reproduce the issue changing Web UI passwords. If you take a look at settings.dat right before the error is logged, you'll notice there are multiple keys for something. In my case, it was the mainwnd_split key. Additionally, I noticed in my settings.dat that caused the error, the keys aren't even sorted correctly.

There was also a bug with Web UI passwords changing every time the Preferences are changed. Overall, there are some funky settings issues (in 1.8.1?) that definitely need fixing/tweaking.

[GTHK]

Before the error is logged? In my case, it happens at the moment I press apply

[Ultima]

Yes, before you press Apply/OK in µTorrent to cause the Logger error to show up. Ryan is currently investigating the issue, BTW

[Ultima]

FWIW, it seems like Ryan has this bug fixed. It'll bug you about a duplicate one more time with these b0rked settings.dat files (naturally, as they are sorta b0rked with duplicate keys), but it should hopefully not happen again. The bug was indeed related to connection setting resets mentioned in the 1.8.1 beta thread, as that too appears to be fixed.