Still ranting on...
If the PC request sector 0 it gets a file system description. IIRC same defines the sector where the FAT starts, where the root dir starts and where the file area starts. I'd do an FAT 16 simulation using 32 K clusters. This information is static (always the same).
If the PC requests a sector of the root file system it gets the description of the files provided. This information is static, only the files' sizes can be set according to the current situation. The file's start sectors can be something like 0x100, 0x200, 0x300, ... I suppose a single sector (normal is 512 bytes) will be sufficient (or do you plan for a huge number of files)
If the PC request a sector from the FAT you can calculate these 512 bytes to represent sector sequences like 0x100, 0x101, 0x102, ...,
0x200, 0x201, 0x202, .... 0x300, 0x301, 0x302, .... the sequence length done according to the max file length you want to support. This information is static but I suppose it's better to calculate it on request than to store it somewhere.
If the PC requests a sector (or multiple) from the file area (sector = file area start sector + cluster * (clustersize / sectorsize) ) you calculate the cluster no, and thus the file in question and the relative location of the sector. So you can open the file and read the appropriate bytes and provide them via USB.
Sounds quite doable to me.
BTW.: Where did you fined the g_file code ? I'd like to take a look at it but googeling did not show a location.
-Michael