This has come up in the forums a good bit, and I'm sure it's covered in other blog posts as well, but given the times it comes up, having another blog post for potential search engine matching seems like a decent idea (and, well, Adam told me to).

Today's version of the question shows up in this forum thread.  The basic premise is "I have c:\binaries mapped to a server folder that has a bunch of binaries in it - I delete some of them (for whatever reason), and expect them to get downloaded again when I next run Get - why aren't they?".  Here's the response I posted: 

1) The behavior of "get" not re-downloading the files you've manually deleted is intentional - "Get" calculates the files you need to download based on what the server thinks you have in your workspace (for huge trees, this is obviously much faster than scanning your entire hard drive to figure it out).  Only when you "force" the get does it ignore what you already have in your workspace and download the files anyway.

2) The "get latest" option from the context menu has no option for force - that's only available on the "Get specific version" choice, as you've seen.  However, you could do this easily via a VS addin if it's something you wanted to do often.

Without knowing your specific scenario, I'm not sure why you're deleting the binaries through windows explorer.  However, one option may be to instead delete them via the Source Control Explorer (or the command-line with tf.exe) by pending a delete on them.  Then, when you want the files back, you can undo those deletes and the files will be downloaded again. 

If the original problem was that the contents of the binaries folder were read-only and that was causing build problems, you could pend edits on the contents of the folder and that would change the files to read-write, at which point your build process should be able to overwrite them.

In general, you don't want to make changes to your local files without using Team Foundation commands - the Team Foundation server won't know about the change, and future commands (like the "get" results you're seeing) won't be able take those changes into account.