T doesn't auto-verify and seed when opening a torrent whose data is already locally present

[m1b]

I have ongoing, consistently reproducible situations where I download a torrent's data outside of T. I then open the .torrent, which is supplied by the data's source (and is running the tracker), in T. I would expect T to notice that the single data file is already there, verify the data, and then begin seeding. Instead, it acts as if the data isn't there and tries to start downloading. The workaround in this situation is to immediately tell T to manually verify the local data. It has no difficulty doing so, and upon completion seeding commences.

It basically behaves as if it can't tell the local file exists until I do the manual verify.

Oddly, once I've done the local verify, I can delete the .torrent from the queue, quit T, relaunch, and readd the .torrent and it will immediately start seeding. Ie this bug is a once-per-torrent only bug -- once the verify happens, something changes somewhere and for that .torrent + data file combination is forevermore ok. I've also tried removing the fast resume cache to see if that makes a difference, and it doesn't. I've verified the mod dates on the .torrent to be sure that they aren't being changed and they aren't. I verified that HFS+'s case insensitivity wasn't masking the problem and it isn't.

This behavior is new to 0.96+ -- all 0.9x release builds behave correctly.

[charles]

tentatively setting for 1.00 milestone because I think I know what's causing this and because it seems to bite a lot of people.

[charles]

fixed in r4425 + r4426.