I appreciate your mathematical approach, but let me set your mind at ease. For assumption 1, I have proven it out by using the handy tool called "dd" plus another fantastic mathematical convention. By taking the total file length and dividing it by the total number of records contained within I was able to find the blocksize for each record.

blocksize = filesize/total_num_records

To further prove this, I know that each block starts with a customer name. So with the handy tool 'dd' I can move to an arbitrary record. If my blocksize is off, then I will not have the name starting the block.

dd if=filename bs=550 count=1 skip=2000 | od -Ad -c

The previous statement moves me to block number 2000 and allows me to see one instance of that block (in hex format). The name is at the correct location so we have proven that 1 is not the case.

For statement number 2 let us refer to the file itself. Since it is in binary format, and since it is a database type file it is logically broken up into these blocks. These blocks in the database world are also called "rows". Although they can have empty locations, the system has allocated these spaces before hand. These previously allocated spaces will still exist in the binary file, even though it is filled with nulls or (in the hexdump) \0.

One more thing I would like to point out, is that I find it quite useful to approach the problem from a different angle. Most developers would never think to come from the standpoint you have suggested. Thank you for those thoughts