That's a particularly good question. I also use (used to, I'm in transition at the moment - or thinking about it anyways) state to represent the stuff that is to be drawn to the screen (CreditsState, GamePlayState, MainMenuState). Normally I'd put those in a folder within the project by themselves called 'States'. I also use a simple class that maintains which state is currently running, and switches between them when needed called the 'StateManager'.
I found working on RB's first couple of collaborations a little difficult, because he also uses State, or GameState, but it represents something completely different. His GameState is a collection of items to be rendered at any one given time, and from what I understand he simply changes the objects within GameState. Strange, eh?
So, personally I agree with Marcus on keeping the GameState stuff as it is. It actually took me a while to understand what was going on with just it, and seems like a good fit since when the 'state' changes, so does everything being rendered.
I'd probably change the file stuff to 'FileManager'. I use the Manager moniker pretty often on different aspects… like the StateManager. To me, it represents a higher order, or collection of the sub-objects, kind of like a distributor in a car, and manages their actions. It links to a bunch of other parts (states, or in this case spark plugs), and tells each part when it's their turn to do something. I'm actually using a FileManager in my text game, but in this case, it loads and parses the text data file into the various game objects that represent 'rooms'. It could also easily be used to load or save a 'gamestate' representing the players progress. I think I'd probably agree with Marcus on that too - to make things easier to follow I'd probably use something like SaveData or perhaps PlayerProgress.
Well, thats my 2 cents, hope it helps!
