- your program runs, and saves an offset
- the data file is deleted, and filled back by the other program to exactly offset.
- your program runs again and does what?
Point taken. I suppose it's more robust to take into consideration the content of the file.
The binary file is a dumping ground for partial ascii/partial binary data. Something like this:
01031327SKY9958 2019-10-18 00:51:36 AXYS_SSP
01031327SKY9958 2019-10-18 00:59:47 AXYS_SSP
01031327SKY9958 2019-10-18 01:00:30 AXYS_SSP
Œ M Ž X¾$ 2(JA >:ú @
Ð }¬²2 " þ h¼Ò ÿ «P €
Where each record, denoted by the header
01031327SKY9958 YYYY-MM-DD HH:MM:SS AXYS_SSP
, comes from one of a few data sources (call each a sensor "output"). In this case, there are 3 unique kinds of outputs -- one relaying GPS coordinates, another from sensor 1, another from sensor 2. I only call it a binary file because it contains data that's meant to be parsed byte-wise (like the third output).
The ordering of data output is not fixed (i.e., sensor output is written asynchronously to the file). Also, one record might be garbled with another (considered to be garbage).
There are many strategies to parsing this file for the most recent record. What I was going to try first was:
Write a regex for the header's form and match anything in between two headers (or header and EOF) as data. That way, we can just parse the small file entirely for timestamp strings and use them as keys to determine whether new timestamps exist.