[rsync]обнаруживать перемещения и переименования

ЕМНИП, суммы он использует в последнюю очередь, когда, например, у файлов разные mtime, но размер совпадает. Вроде так.

http://en.wikipedia.org/wiki/Rsync#Algorithm

где тут написано, что он угадывает факт переименования файла по его контрольной сумме?

GotF> суммы он использует в последнюю очередь

дык это чудо юзает -c — принудительно считать checksum

в гугле есть ссылки на экспериментальные патчи. Если у тебя гента то можно попробовать :)

>где тут написано, что он угадывает факт переименования файла по его контрольной сумме?

Я не утверждал, что это где-то написано. Просто это логично. rsync нужен, чтобы экономить трафик при синхронизации директорий. Иначе какие у него преимущества перед rm -fr && scp -r ?

>дык это чудо юзает -c — принудительно считать checksum

Чем это плохо?

Конечно, перемещать файлы стоит не только по чексумме, но и по совпадению размера во избежание коллизий. А вот времени модификации я не очень доверяю. Бывало, что оно оказывалось разным у одинаковых по содержимому файлов по неустановленным мною причине.

>в гугле есть ссылки на экспериментальные патчи. Если у тебя гента то можно попробовать :)

Отлично! Только я ну никак не могу придумать подходящий запрос, чтобы их найти :(

Может поможите?

>экономить трафик при синхронизации директорий

экономить трафик при синхронизации файлов, прочитай ещё раз по ссылке

Гуглил по rsync detect renamed files и rsync handle renamed. Вот что-то нагуглилось:

http://samba.2283325.n4.nabble.com/DO-NOT-REPLY-Bug-2294-Detect-renamed-files...

Я думаю самый эффективный способ работать с переименованиями это держать базу по всем файлам(filename, inode, mtime, etc). После переименования инода остаётся старой, поэтому можно определить это. Но rsync, вроде, так не умеет. А расчитывать контрольные суммы для больших файлов неэффективно т.к. приходится считывать файлы целиком. А это дисковое io, пустая трата кэша, итп. В общем, rsync, увы, не идеален.

так иноды то разные источнике и приёмнике. rsync - stateless утилита, он не хранит данные о приёмнике(ах).

ТС'у нужна система контроля версий, некоторые из них понимают переименование.

Я об этом задумывался, старое имя файла в базе на источнике можно хранить. Но, конечно, нюансов тут куча, я согласен.

я думал в сторону контроля версий, но с ходу не нагуглилось такого.

bzr умеет

не подходит. Допустим тебе надо отслеживать 30-гиговые файлы. Он же их себе в репу попытается добавить. Соответственно это будет двойной расход места и жуткие тормоза в работе(прикинь сколько diff оно делать будет или добавление нового файла).

В общем, нужно специализированное решение.

Спасибо. Попробую этот патч.

База по всем файлам - это по-моему уже отход от принципа KISS. Я ещё кстати почему по чексуммам всё делаю, чтобы например

cp file tmpfile; rm file ; mv tmpfile file

проходило незаметно для rsync. Во варианте с отслеживанием mtime или inode такое «изменение» бы детектировалось. Такое слишком «умное» поведение плохо, если я хочу (а я хочу) иметь возможность производить мержинг вручную.

А то, что нужно считывать большой файл целиком меня не очень парит, так как делаю мерж не чаще чем раз в неделю.

Насчёт систем контроля версий и почему они для таких задач, на мой взгляд, не подходят.

Ну во-первых, хранение старых версий здесь не нужно, у меня и так около сотни Гб мержится и на хранение старых версий не хватит никакого дискового пространства. (хотя может эту функцию можно отключить)

Системы контроля версий позволяют обнаружить конфликтные изменения и вручную их смёржить. Это хорошо для работы с plain text файлами (исходниками), но для бинарных файлов скорее создаст проблемы. Гораздо лучше иметь одно место, где предполагается, что всегда лежит самая правильная версия всех данных, а остальное синхронизировать с ним.

Опять же, изменения в стиле

cp file tmpfile; rm file ; mv tmpfile file

или просто синхронные изменения в двух местах будут восприняты как неоходимые для мержинга, а это не требуется.

В master-хранилище файлы будут лежать в каком-то своём, недоступном для простого редактирования виде, и прежде чем к ним получить доступ, как и в других местах нужно сделать check out - то есть нужно хранить там данные в двух экземплярах по-сути (если к ним доступ всё же нужен, а у меня это так).

проходило незаметно для rsync

ммм, в каком смысле незаметно? У меня он детектит и пересылает «новую» версию файла.

База по всем файлам - это по-моему уже отход от принципа KISS

а иначе быстро задачу не решить. Всё же пересчёт контрольных сумм это тоже неправильно.

при моих опциях (скорее всего как раз из-за -c) не пересылает.

Ну тут палка о двух концах... даже о трёх: либо пересылаем лишние данные, либо больший износ оборудования, либо хранение метаинформации со всеми вытекающими (что я перечислял ранее) неудобствами и непрозрачностью процесса.

С учётом того, что у меня и так всё основано на контрольных суммах (а значит износ харда уже принесён в жертву), то хотелось бы избавиться от лишнего трафика, ведь для меня это окажется «бесплатно».