Microsoft File Transfer Manager

I wanted to blog today about something that had been nagging at me ever since I started being a beta tester for some of Microsoft's products.

Those of you who participate in one or more of the beta programs will have noticed how the only way to download products that are larger than a set size (I think it's 100mb) is through the Microsoft File Transfer Manager.

I've never grown too accustomed to that download manager - it's clunky, quirky and more often than not, way too slow (I know - that's because of throttling done on the server side to allow for more concurrent downloads, especially when the item is, say, the new Windows7 beta and the number of downloaders can be over a million).

Lately, though, I've been pestered by another unwelcome FTM trait: No matter how many times I'd hit Cancel, the download candidate file would be temporarily removed only to come back in force after FTM was restarted. Multiply this with many aborted download attempts and I was suddenly faced with having to hit "Cancel" and "Yes, REALLY" for all my previous canceled items every time a new beta was out that I wanted to test. This quickly turned out to be more than I wished for (twenty repeat "Cancel" and "Yes" kinda wear you out after awhile) and I was pushed to look for a solution.

No amount of googling would point me to the right direction though: How to REALLY delete those old, aborted download items so they will not reappear at next FTM start.

Then I remembered Mark Russinovich and his very cool toy: Process Monitor. A bit of filtering for "transfermgr.exe" showed that when the app starts, it looks in %appdata%\Roaming\Microsoft\File Transfer Manager\RequestQueue for its list of download candidates. Where FTM would fail to delete the ones I'd hit "Cancel" on, I would NOT. I removed the contents of the RequestQueue folder and Presto! problem solved!

Gotta give it to Mark Russinovich... Good work man!