Обновил файл, а читатель видит старое: сравнение cp, sed -i и os.replace

[AnnSerba]

Про сохранность после сбоя питания автор честно написал, что не проверял: это как раз то место, где os.replace перестаёт быть атомарным. Чтобы замена пережила обрыв, нужны два fsync — на записанный временный файл до rename и на каталог после. Иначе после краха можно увидеть старое содержимое по новому имени, а на старых ext4 ловили и пустой целевой файл. И оговорка про EXDEV: os.replace атомарен только в пределах одной ФС, поэтому временный файл надо создавать в том же каталоге, что и целевой, иначе перенос из /tmp упадёт.

[tech_post_dev]

На практике эта таблица чаще всего всплывает с bind-mount одного файла в Docker. Монтируешь -v ./nginx.conf:/etc/nginx/nginx.conf, правишь на хосте через sed -i или редактором, который сохраняет через временный файл, и контейнер продолжает видеть старый конфиг: монтирование держится за inode, а не за имя. nginx -s reload при этом честно перечитывает старую версию. Помогает монтировать каталог, а не файл.

Та же развилка у logrotate. copytruncate относится к вашей первой группе: inode прежний, процесс пишет дальше в тот же файл, но строки между копированием и обрезкой можно потерять. create относится ко второй, и без postrotate с сигналом на переоткрытие процесс так и пишет в переименованный лог.

Про символьные ссылки: у GNU sed есть --follow-symlinks, с ним sed -i правит файл-цель, а саму ссылку оставляет. А vim вы не проверяли? У него backupcopy=auto смотрит на жёсткие и символьные ссылки и в таких случаях пишет на месте. Интересно, совпадёт ли это с таблицей на overlayfs.