Well, apparently for some reason known only to the Electron Gods, if I perform a "Save As" the new file disappears as soon as the thumb drive is removed from the computer. 
But if you save it to a hard drive and then copy it back to the thumb drive then it remains. 
...
Dozen make know cents 
It makes perfect sense! ... to people that know what "the dinosaur book" is and hung out in Unix/Linux labs in college. :)
I'll try and explain this the best I can. The last time I got deep into the issue it was to fix a 2 year old known bug in some software. I was rather surprised when I came onto the project that the ideas below were a foreign concept to the team because they were very competent individuals.
Any sane OS (operating system) is going to tread lightly on its storage. Windows started getting with the program with the NT kernels but you'll still see it immediately dump stuff to disk sometimes, which is OK, sometimes, but I still think Explorer does it too much.
Anyway...
Your OS keeps an internal buffer of stuff it needs to write to disk in memory. This is useful because if you change your mind on something you don't need to actually wait for all the I/O to occur before you can swap it back out. Or your'e hammering your disk constantly saving the same file over and over again with minimal changes, like you would in a word processor.
The OS just lets these changes pile up and plops them out to the actual disks whenever it feels like it. Mostly. As a programmer you can force the OS to actually commit something to disk. In the *nix syscall library it's the fsync() call and in Win32 it's _commit(). Hit those calls on an open file handle and it tells the OS: Go to disk NOW!
If you just fclose()/_close() the file, as a programmer, you're leaving it up the OS to schedule the disk write. But, to everything else on the system the file is already in place. That's why you can save the file from your word processor to disk, see it in Explorer, and then attach it to an email.
Sometimes these changes awaiting write can last in memory longer than you'd think. The last time I got into it professionally it was to fix a bug in some Windows application. An event would occur in the app, it would open up a file, stream a tiny (128 bytes or so) amount of data to disk, close the file, and keep on trucking. The original developers were stumped. They'd trigger the event, see the file on disk, inspect its contents, scratch head, read it again, yeah, still there... kill power to the machine 2 minutes after event. When the machine booted back up the file was empty. I just went bouncing through the code and did a quick _open()/_commit()/_close() call on every file in question after a write operation and the problem disappeared.
