Эта rename()функция для обычных файлов эквивалентна той, которая определена стандартом ISO C. Его включение здесь расширяет это определение для включения действий над каталогами и определяет поведение, когда новый параметр называет файл, который уже существует. Эта спецификация требует, чтобы действие функции было атомарным.
#include <stdio.h>
int rename(const char *old, const char *new);
Описание
renameФункция вызывает файл, имя которого является строка , на которую указывает oldбудет отныне известный под именем , заданным в строке , адресуемой new. Названный файл oldбольше не доступен под этим именем. Если файл, названный строкой, на которую указывает строка, newсуществует до вызова renameфункции, поведение определяется реализацией.
Возвращает
В renameФункции возвращает ноль , если операция прошла успешно, отлично от нуля , если это не удается, и в этом случае , если файл ранее существовал он по - прежнему известен под своим оригинальным названием.
Удивительно, но обратите внимание, что нет явного требования атомарности. Это может потребоваться где-то еще в последнем общедоступном стандарте C, но я не смог его найти. Если кто-то может найти такое требование, редактирование и комментарии приветствуются.
Если он newpathуже существует, он будет атомарно заменен, так что не будет точки, в которой другой процесс, пытающийся получить доступ
newpath, найдет его отсутствующим. Однако, вероятно, будет окно, в котором оба oldpathи newpathссылаются на переименованный файл.
Справочная страница Linux утверждает, что замена файла будет атомарной.
Однако проверить и проверить, что атомарность может быть очень трудным, если вам нужно продвинуться так далеко. Вам не ясно, что вы имеете в виду при использовании «Как я могу проверить, является ли mv атомным». Вы хотите, чтобы требования / спецификация / документация были атомарными, или вам действительно нужно их протестировать ?
Также обратите внимание, что в приведенном выше примере предполагается, что имена двух файлов операндов находятся в одной файловой системе. Я не могу найти стандартного ограничения на mvутилиту для обеспечения этого.
Я должен убедиться, что этот шаг является атомным. Тестирование достаточно, чтобы принять это? Я не могу сказать. Да, я работаю над тем же фс (от ext4 до ext4).
Тицианорейка
1
POSIX также не гарантирует атомарность, но Linux, как и большинство вариантов Unix, делает это для «родных» файловых систем, таких как ext4.
Жиль "ТАК - перестань быть злым"
1
Учитывая, что ISO C определяет поведение только одной программы, а не всей системы, было бы странно говорить что-либо об renameатомарности.
Жиль "ТАК - перестань быть злым"
3
Я прочитал «эту спецификацию» как ссылку на предыдущее предложение («Его включение здесь ... определяет поведение, когда новый параметр называет файл, который уже существует»), которое ссылается на более ранние части документа POSIX («ссылка с именем new остаются видимыми для других потоков ... и ссылаются либо на файл, на который ссылается новый, либо на старый ... "). Другими словами, POSIX обещает внедрить стандарт ISO C и дает дополнительные гарантии сверх того, что обеспечивает ISO C. Это толкование помогает?
SimonJ
1
@Tizianoreica Я знаю, что это древний пост, но я только что увидел ваш комментарий и подумал, что должен уточнить: фактическая файловая система должна быть такой же, чтобы переименование было атомарным. Не только тот же тип файловой системы. Например, если у вас есть /ext4 fs и /tmpкак другой ext4 fs, то вы не можете атомарно mv от одного к другому.
Водин
0
mvоснован на renameсистемном вызове и rename()является атомарным. Вы можете посмотреть на справочную страницу rename(2).
В дополнение к проверке системных вызовов и их атомарности, может inotify-toolsслужить тестом, хотя я не уверен, является ли это гарантированным доказательством атомарности.
Откройте 2 снаряда. Посмотрите целевой каталог перемещения в одном из них:
inotifywait -m target/
Переместите файл в другой каталог:
mv foobar target/
inotifywaitДолжен показывать только одну строку:
target/ MOVED_TO foobar
Он кажется атомарным по сравнению с ответом на ls target/и touch target/a, который выдает многострочные сообщения, такие как:
# the response to ls target/
target/ OPEN,ISDIR
target/ ACCESS,ISDIR
target/ CLOSE_NOWRITE,CLOSE,ISDIR
PS
Я думаю, что, по крайней мере, это показывает, что асинхронное многопроцессорное взаимодействие с файлами безопасно inotify(практически атомарно): в любом случае вы отвечали бы только после того, как inotifyдали окончательный сигнал после операции. Например, установка «производитель-потребитель» может быть легко и безопасно реализована inotify.
strace
?unlink
илиrename
переносимый и атомарно сделатьlink
не получится ?Ответы:
Интересно, что ответ может быть «Это зависит».
Чтобы было ясно,
mv
как указано вСпецификация функции переименования гласит:
Но последняя спецификация ISO C для
rename()
государств:Удивительно, но обратите внимание, что нет явного требования атомарности. Это может потребоваться где-то еще в последнем общедоступном стандарте C, но я не смог его найти. Если кто-то может найти такое требование, редактирование и комментарии приветствуются.
Смотрите также Является ли rename () атомарным?
Согласно справочной странице по Linux :
Справочная страница Linux утверждает, что замена файла будет атомарной.
Однако проверить и проверить, что атомарность может быть очень трудным, если вам нужно продвинуться так далеко. Вам не ясно, что вы имеете в виду при использовании «Как я могу проверить, является ли mv атомным». Вы хотите, чтобы требования / спецификация / документация были атомарными, или вам действительно нужно их протестировать ?
Также обратите внимание, что в приведенном выше примере предполагается, что имена двух файлов операндов находятся в одной файловой системе. Я не могу найти стандартного ограничения на
mv
утилиту для обеспечения этого.источник
rename
атомарности./
ext4 fs и/tmp
как другой ext4 fs, то вы не можете атомарно mv от одного к другому.mv
основан наrename
системном вызове иrename()
является атомарным. Вы можете посмотреть на справочную страницуrename(2)
.Вы могли бы найти ответ на Является ли rename () атомарным? на стеке потока
Что за фс, вы использовали?
источник
В дополнение к проверке системных вызовов и их атомарности, может
inotify-tools
служить тестом, хотя я не уверен, является ли это гарантированным доказательством атомарности.Откройте 2 снаряда. Посмотрите целевой каталог перемещения в одном из них:
Переместите файл в другой каталог:
inotifywait
Должен показывать только одну строку:Он кажется атомарным по сравнению с ответом на
ls target/
иtouch target/a
, который выдает многострочные сообщения, такие как:PS
Я думаю, что, по крайней мере, это показывает, что асинхронное многопроцессорное взаимодействие с файлами безопасно
inotify
(практически атомарно): в любом случае вы отвечали бы только после того, какinotify
дали окончательный сигнал после операции. Например, установка «производитель-потребитель» может быть легко и безопасно реализованаinotify
.источник