Possible flaw in navobj backup

[CSYChip]

I am running OpenCPN on a raspberry pi and have lost the contents of navobj.xml and all its backups. Another program was writing spurious data to the system logs until it filled the SD card. This caused OpenCPN to lock up updating the charts. Not knowing why it locked up I closed OpenCPN and restarted it. The all of the navobj files and the opencpn.log file now have a size of 0. opencpn.log.log was not effected. I assume the data was all in ram and therefore is not recoverable. Does the renaming sequence which backs up the navobj files check if there is sufficient space? If not, should it?

[nohal]

Originally Posted by CSYChip

Does the renaming sequence which backs up the navobj files check if there is sufficient space?

No.

If not, should it?

I'm not too sure it will make the situation much better in these cases, but it could of course be made more robust than it is.

[CSYChip]

I'm guessing from the fact than the old navobj.xml.1 etc went to a file size of 0 that they are copied or moved when the new one is created rather than just renaming the file allocation pointer.

Does opencpn.log write to disk or is it held in memory until the program closes? I am looking at trying a forensic recovery to see if the old files are still on the SD. I lost a month of data but opencpn was closed and re-started several times in that period.

[bdbcat]

"Does opencpn.log write to disk or is it held in memory until the program closes?"


Log file is flushed "occasionally", as and when the main app event queue becomes empty. Of course, the massage queue is flushed on program exit.


Good Luck
Dave