Well, the total size (or is that the remaining size, modulo the size of the clusters on the partition? I'd have to look it up, sorry) is stored in the directory entry. The FAT cluster-chain is a linked-list, terminated by 0xFFs. There can be remaining data left over in the end of the cluster, that's why when CHKDSK or SCANDISK recovers "lost clusters" and turns them into those FILE0001.CHK files, there is garbage at the end.
Also, some DOS apps, when dealing with sequential (text) files, will append a DOS EOF character (CTRL-Z, 0x26) at the end. Not all editors do that, and some will strip that when reading the file, and then write it out without it.
Interesting little bit of trivia - there is a bug in the sequential file read/write APIs in MS-DOS 5.0. If you attempt to read or write chunks of *exactly* 64KiB in size, sometimes a carry flag gets lost somewhere in DOS's internals, and the DOS file-position ptr won't get properly incremented. In essence, if you write two 64KB chunks, the second may overwrite the first. The suggested workaround is to read and write data in 32KB chunks instead. I saw that documented a long time ago, and I didn't believe it, until it finally happened to me. That's what finally got me to upgrade to MS-DOS 6.x.
