RedoxFS научилась атомарно переименовывать без затирания цели

14.12.2025

В файловой системе RedoxFS реализован флаг RENAME_NO_REPLACE: переименование, которое отказывается выполнять, если целевое имя уже занято. Это аналог Linux-флага с тем же именем.

Какую ошибку это снимает

Обычное переименование безусловно: если на месте целевого имени что-то есть, оно будет затёрто. Между проверкой «свободно ли имя» и самим переименованием есть окно, в котором другой процесс может занять это имя.

Сценарий нередкий: программа создаёт временный файл, затем переименовывает его в постоянный. Если параллельно запустится вторая копия той же программы, один из файлов может перезаписать другой, и данные потеряются без всякой ошибки.

RENAME_NO_REPLACE делает проверку и переименование одной операцией: либо имя свободно и файл переименован, либо система отказала.

Чем отличается от Linux

В Linux есть два похожих механизма. RENAME_NOREPLACE — это. Второй — RENAME_EXCHANGE, который меняет местами два файла, существующий — на несуществующий.

Почему это важно на практике

Атомарное переименование — основа безопасных операций с файлами. Из него делают безопасную замену: создать новый во временном имени и переименовать на место старого. Если переименование умеет затереть, такой приём небезопасен, и приходится писать проверку в два шага, которая снова создаёт гонку.

Для кода на Rust это снимает характерный источник дефектов. Стандартная библиотека не предлагает такой приём, поэтому приложения обычно реализуют его сами — и часто неправильно.

Отмечу отдельно: тот же месяц принёс другую правку с похожим смыслом — удаление файла теперь откладывается до закрытия всех открытых дескрипторов, то есть появилась семантика «удалить при закрытии». Обе вещи делают работу с временными файлами предсказуемой.

Оригинал

Коммит Implement RENAME_NO_REPLACE от 14 декабря 2025 года в репозитории redox-os/redoxfs, добавлен автором Josh Megnauth; сводка «This Month in Redox — December 2025», раздел «RedoxFS Improvements»

Упоминаний: 1 · Просмотров: 3