Fall back to truncate + write when config file is busy

[Abestanis]

Issue

When updating bridge configs, the new config is written to a temp file and then replaces the existing file using os.Rename here:

go-util/configupgrade/upgrade.go

Line 153 in fc01e95

err = os.Rename(tempFile.Name(), configPath)

This is a very safe approach because renaming is atomic, so chances of loosing the config are minimal.

Unfortunately, it does not work when the config is a mounted file in a docker container like in this example:

  whatsapp-bridge:
    image: dock.mau.dev/mautrix/whatsapp:latest
    volumes:
      - ./config/whatsapp.yaml:/data/config.yaml

It produces an error like this:

Error updating config: failed to override current config with temp file: rename ./mautrix-config-1962078080.yaml config.yaml: device or resource busy

Replacing the file does not work in this scenario, but truncating and writing would work. But it would no longer be atomic.

Solution proposal

If the replace fails with device or resource busy, could we fall back and try truncating and writing? This would increase the risk of loosing the config value, but it's still very minimal because we only copy from a temp file so the generation is already done, and we would only do this after os.Rename had failed as a fallback.

If necessary, we could even copy the original config into a backup before truncating, and then attempt to restore if writing the new config fails (although this seems overkill and likely not helpful, because writing back the backup will likely also fail).
Or we could make this an opt-in config option in the bridge.

Does this sound reasonable? I would be willing to provide a PR. Thank you for providing these awesome bridges!

[tulir]

Probably better to just mount the directory and override the docker startup command if you want to use a different file name, e.g. command: ["/usr/bin/mautrix-whatsapp", "-c", "/data/whatsapp.yaml"] (bypassing the startup script also allows running the image directly as a different user rather than starting as root and su-exec'ing later)

[Abestanis]

Thank you for the fast response! That would be an option, but the folder contains config files from other bridges too, and I don't want to give access to the other config files to all bridges, and I would like to keep this folder structure and avoid having to have one folder per bridge.

I only found out that this is an issue because I was inspecting the logs for an unrelated problem, the bridges work otherwise. But I'm afraid that the config file is going to get more and more outdated and in the future you might drop the support for my config version that hasn't been updated. I might not be the only one who attempts this configuration for various reasons, and did not really realize there was a problem, so I think this might still be something worth changing. I understand if you disagree, feel free to close this issue in that case.

[Abestanis]

Thinking about this a bit more, I'm more and more convinced that it's a good fallback behaviour. The risk of loosing the config file is extremely minimal, and since it's a fallback it would only affect those who mounted the file directly like me.

Implementation wise, this should be very straight forward, we already have the new config version in a temp file, so we just have to open the config file in truncation mode and io.Copy the contents over.

I would like to get started on a PR, please let me know if this is something that you would accept or if it's not something you want to do.