I always recommend that you plan the program so that it can be re-run successfully if for any reason it does not succeed.   This means being “non-destructive” of the program’s inputs.   Instead of actually overwriting the input file to “remove” certain records, the program produces, as one of its several outputs, a new version of its input-file which “omits” certain records.   Then, if everything goes according to plan, that output-file becomes the input-file that will be used in the next run ... but the previous input-file also is still there.   (And maybe several of them, logrotate style.)

This is a very good strategy for a lot of good reasons:   for one thing, you can easily diff the two files (“before” and “after”) to be certain what it actually did.   You can objectively analyze the situation, and you can reliably do a re-run if necessary.

(If you really do need to update a file in-place, I suggest that you use a database-file format such as the ubiquitous SQLite ... but, even then, that you do not actually delete the successfully-processed records right away.   Instead, “soft-delete” them in some way, such as by writing a timestamp to a field that will be NULL for any records that are yet-to-be-processed.   Give yourself a source of history, as well as something that can be reversed should the need arise.   “Ka-ka occurs ...”)