@Daniel Beardsmore said:
As for the OP, what's more annoying about those installer directories dumped at the root of a random drive is that, often, they're not cleaned up, and they're locked down so that you can't remove them manually without a custody fight against the OS. (UAC and its ilk cause a lot of problems: it destroyed all the workarounds for permitting non-admin users to install fonts (since Windows still has no per-user font installation), and it also prevents you from deleting corrupt print jobs, while Microsoft have still failed to add a single ounce of troubleshooting to the Print Spooler service. Print Spooler will still crash on load endlessly if there's a bad job in the queue, without ever twigging that there's a problem, and offering no official way to ever resolve it. How hard would it actually be to have a flag that detects that the spooler crashed when loading a print job, and throw it away? Otherwise, you have to open up the spooler directory and remove the files by hand, except you can't any more.)
Don't get me started on removing corrupt print jobs. Print jobs on my parents' computer (windows 7) often get corrupt for a mysterious reason and hang up the spooler completely. The only way to get it resolved is to unplug the printer, reboot, stop the spooler and hope it lets you remove the files from the spooler directory (which 9 out of 10 times works). It would save me a lot of time if I can just tell them to remove the job from the spooler window and try again, instead of doing this procedure myself because it gets to complicated for them.
On the dumping of installer stuff on root directories, MSSQL does this as well as I discovered when I found I needed to install some components, after I mounted the Truecrypt container with the data I wanted to add to the database. The installer ended up on the root of this container which is on a USB 2.0 thumb drive, making the installation process very slow. This thread reminds me to check whether it cleaned up after itself or not.