Hum... no. And here's what I did: if you try to read a record whose number is marked as deleted, a RecordNotFoundException is thrown. Take a look at the interface that was provided to you; if your readRecord throws RecordNotFoundException, then you can throw it.

When I delete the record, I just set the flag byte and put that deleted record number to a Map. When I add new record, I check the Map for the deleted record. If any, I use that record number and overwrite the bytes on that record number (I think it is what the specification means on "making the record number and associated disk storage available for reuse."). If not any, I use the last record number + 1.

Whatever your choice, just make sure it is not against the specification and make sure that you document it. Please consider the other's opinion too.

Not to put a spanner in the works, I've been considering a logical delete rather than a physical delete.

Advantages include:
- a clear trace of deleted records if any disputes arise (either by the customer or contractor company)
- a clear trace for any legal auditing
- clearer code for a junior programmer
- a more open implementation (in the case client really does want a physical delete in the future)

As far as the must requirements, here is my take:

I read this as "marking the record's storage bits for reuse".

Here is the open part: by using the words 'possibly reusing a deleted entry', does this mean:

A) In the case that there are deleted records, you must reuse them (the physical bits).
or
B) In the case there are deleted records, you may wish to consider reusing a deleted entry (the physical bits).

There is also another interpretation: C) Reuse a deleted entry in the sense of making a deleted item active again.

The "status" flag tells us whether the record is valid or not. So, if a record is marked as "deleted", then it only exists in the file and this entry can be reused. For instance, in the case of the URLyBird assignment, it shouldn't be possible to book a room whose record is deleted. The records to be displayed in the JTable should only be valid records. So, Ehsan is correct by only considering it as a logical delete.

Ehsan Rahman wrote:A) In the case that there are deleted records, you must reuse them (the physical bits).
or
B) In the case there are deleted records, you may wish to consider reusing a deleted entry (the physical bits).

Some people chose not to reuse deleted entries and justified this choice. I myself chose to reuse deleted entries.

Ehsan Rahman wrote:There is also another interpretation: C) Reuse a deleted entry in the sense of making a deleted item active again.

This is not a requirement, that is, making a deleted record active again. So, once it is deleted, it is deleted (and deleting a record is not also a requirement of the assignment). A new record can fit this position in the .db file, overwriting the old record (and creating a record is not also a requirement). But even though creating or deleting records are not a requirement, these methods must have valid implementations.

In my approach I have chosen to display deleted entries. If the user wants can then undelete the hotels records. The deleted records are marked with red colour in the JTable in order to distinguish from the other. According to my opinion its up to the developer and how the solution will be justified on the choices.txt in order to be acceptable..

I used also a map as record cache and when I read the file for the first time I store the recNo with the String array or null (if the record has deleted flag). And that's it!
When I need a record number for a new record I just iterate over my map and if I encounter a null-value I use that recNo as the new record number, otherwise just the size of the map (+ 1 if your recNo is 1-based)