Why are new writes to files not surviving a power loss

I have a similar type of issue to: Raspberry Pi: Filesystem writes files, but after reboot the old data is back but not quite the same.

I am using Armbian_23.02.2_Orangepizero_jammy_current_5.15.93 running on an OrangePi with an SD card for storage.

I built a race timer for a car using C++. It uses GPS and logs data at 10Hz to a file. It also runs a server and I can change some configuration on a webpage that is hosted and this configuration is then stored as JSON in a file so that it survives reboots. The OrangePi is powered from the car and when the car is turned off after a run the OrangePi loses power until the next time the car is started (could be problematic?)

The problem I am having is this: I can launch the server, change some configuration, ssh on, cat the file and see that the new configuration is stored in the file. If I then pull the power, and plug it back in. The file returns to the state it was before the config was changed.

If I do sudo reboot now instead of pull the power the new configuration persists. It seems like the new file data isn't actually being written and held in RAM.

Storing data like this:

void store(const config& c)
{
    const nlohmann::json json = {
        {"key1", c.val1},
        {"key2", c.val1},
        {"key2", c.val1}
    };

    std::ofstream f("/path/to/file.json");
    f << json;
}

When logging data at 10Hz, I append to the end of the file with the new data at 10Hz, I have noticed that sometimes the end of the file is missing some "logs". Also if the current run is faster, the log file for that run will be copied to a different location, I have noticed that the copied data can be "funky". For example I have seen it contain parts of the previous and new log and have the previous file name.

Copying files like:

std::filesystem::copy_file(
    from_path,
    to_path,
    std::filesystem::copy_options::overwrite_existing,
    ec);

Is there anything I can do to force the files to be written straight away?

Is appending roughly 100 characters to a file at 10Hz possibly too ambitious for a single-board computer running on an SD card?

You can use the sync command as root. sync synchronizes cached writes to persistent storage. You can type man sync to get some help on its command line switches if you need something more specific.

You should also make it do an orderly shutdown though. This is often accomplished by using one of the GPIOs to input a shutdown signal, and enough power storage to allow the RPi to act on the signal. You could, for example, power it off a USB battery pack that's charged by the car (ensuring you buy one that will charge and deliver power at once - not all do, including some of the better makes). The GPIO would be driven (I suggest via an opto-isolator) from the 12V ignition on line of the car.

Because it can't monitor the GPIO while it's shut down, you can't start it in the same way. Flipping a switch in the power line is quite an easy way to get it to reboot.

There are also solutions using relays, and no battery beyond the car's own. For example:

• power the RPi's PSU off an always-on 12V line.
• but that line is routed through a relay
• the relay coil is powered, through a diode, by the 12V ignition on line
• the coil is also powered, again through a diode, by a transistor that's switched by a GPIO (the GPIO will go low on shutdown). Again, I'd use an opto-isolator here.
• You still sense the 12V ignition on line using a GPIO, opto-isolated.

This setup means that if either the ignition on signal is 12V OR the GPIO driving the relay is high, power is supplied. That means it will start automatically when you start the ignition