I don't understand why a 00 at the beginning of a record means the record is not deleted, but a 0x8000 means the record is deleted. Hey, either you delete a record, in which case the data file gets shortened. The record NO longer exists, or the record is NOT deleted, it exists.
You would not want to shorten the file, there are no primary keys so you have to use a logical pk (the record number), if someone has a record they are working on (lets say recno 75) and you delete 74 and shorten the file, the user in now on (old 76), also it is specified that you need to check for deleted records when adding, and if found, recycle it, also it would mess up the locking scheme, how would the program know which physical row they were on if someone else is shortening the file? All xBase like languages use a delete flag and delete filter, they also use a header that describes the field layout. I'm sure Sun didn't want to have to grade this exam if people were using an RDBMS, so they when to an old tried and true paradigm.
Hi... Your question is interesting, shortening the file may cause successive data access calls to corrupt the file. But, what if we reconfigure the file at startup? we could scan the file for deleted entries, then physically delete them and ADJUST THE FILE HEADER ACCORDINGLY?