The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск утилиты для синхронизации файлов Rsync 3.3.0. Эндрю Триджелл возвращается в проект

06.04.2024 23:08

После полутора лет разработки опубликован релиз Rsync 3.3.0, утилиты для синхронизации файлов и резервного копирования, позволяющей минимизировать трафик за счёт инкрементального копирования изменений. В качестве транспорта могут быть использованы ssh, rsh или собственный протокол rsync. Поддерживается организация работы анонимных rsync-серверов, оптимально подходящих для обеспечения синхронизации зеркал. Код проекта распространяется под лицензией GPLv3.

Значительное изменение номера версии не связано с функциональными изменениями в нынешнем выпуске, а является отложенной реакцией на значительные изменения в прошлой версии 3.2.7. В версии 3.3.0 отмечается в основном исправление ошибок. Репозиторий проекта на GitHub перенесён из аккуаунта сопровождающего WayneD в отдельную организацию RsyncProject. Также сообщается о формировании новой команды сопровождающих rsync из-за нехватки времени у нынешнего сопровождающего. Примечательно, что в эту команду вернулся Эндрю Триджелл (Andrew Tridgell), основатель проектов samba и rsync, а также Пол Маккеррас (Paul Mackerras), один из первых разработчиков rsync, принимавших в 1996 году участие в создании протокола rsync.

Среди добавленных изменений:

  • В утилиту rrsync (restricted rsync) добавлена опция "-no-overwrite", запрещающая перезапись существующих файлов в целевом каталоге.
  • Вспомогательные скрипты mapfrom и mapto, написанные на языке Perl, переписаны на Python и объединены в общий скрипт idmap.
  • Переписан на языке Python perl-скрипт mnt-excl.


  1. Главная ссылка к новости (https://www.mail-archive.com/r...)
  2. OpenNews: Выпуск утилит для резервного копирования Rsync 3.2.7 и rclone 1.60
  3. OpenNews: Уязвимость в Rsync, позволяющая перезаписать файлы на стороне клиента
  4. OpenNews: Выпуск утилиты для синхронизации файлов Rsync 3.2.4
  5. OpenNews: В состав OpenBSD добавлена собственная реализация rsync
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/60941-rsync
Ключевые слова: rsync
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (50) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Аноним (2), 23:56, 06/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    20 лет feature request'у, а воз и ныне там:

    https://bugzilla.samba.org/show_bug.cgi?id=2294

     
     
  • 2.3, ls (??), 00:05, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    unix вей не позволяет реализовать такие вещи эффективно
     
     
  • 3.5, Аноним (5), 00:13, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    не звезди, при переименовании inode не меняется.
     
     
  • 4.8, Аноним (8), 00:37, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > при переименовании inode не меняется

    Использовать inode — не unix way.

     
  • 4.13, Аноним (13), 06:52, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    и как rsync должен знать про inode?
     
  • 2.4, LeNiN (ok), 00:10, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Тут есть что-то про detect-renamed: https://github.com/RsyncProject/rsync-patches
     
  • 2.7, n80 (?), 00:17, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если не использовать btrfs/zfs (у которых есть свои средства для снимков и синхронизации), опция --fuzzy работала достаточно хорошо, по крайней мере, в моих случаях. По ссылке она упоминается.

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

     
     
  • 3.9, Аноним (9), 01:12, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >можно рассказать про свой сценарий использования

    Синхронизируется каталог с кучей файлов. В какой-то момент каталог переименовывается без изменения содержимого. Так вот rsync в этом случае на целевой машине создаст новый каталог и будет заново качать все его содержимое. Ни какие --fuzzy и, тем более, btrfs/zfs ситуацию не исправляют.

    >надо залезать на уровень кода файловых систем

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

    20 лет назад описан этот кейс и даже предложен патч detect-renamed. Упрямство не имеет логического объяснения.

     
     
  • 4.14, Аноним (14), 09:03, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Напомни почему ты за 20 лет не сделал форк с данным патчем хотябы для себя? Может потому что даже у тебя данный кейс ниразу не случился за 20 лет?
     
  • 4.17, Ю.Т. (?), 09:14, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В какой-то момент каталог переименовывается без изменения содержимого.
    > Всего-то надо проверить

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

     
     
  • 5.20, Аноним (20), 09:55, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Unison вроде умеет такое обрабатывать.
     
     
  • 6.23, Ю.Т. (?), 10:30, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Unison вроде умеет такое обрабатывать.

    Я говорю о том, что даже если мы на 101% имеем идентичные файлы, то (для западного универсанта) из этого не следует однозначно возможность считать сущность с другим названием тождественной этой.

     
  • 5.50, Аноним (9), 20:16, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >Мало ли что файлы с одинаковыми размерами, или даже одинаковые хэши

    Для любого, западного или восточного, реального практика (в смысле "не теоретика") равенство хэшей sha1 означает, что файлы идентичные.
    >не та семантическая разница

    Сферический конь в вакууме.

     
     
  • 6.52, Ю.Т. (?), 22:58, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>Мало ли что файлы с одинаковыми размерами, или даже одинаковые хэши
    > Сферический конь в вакууме.

    Вот потому у них и многое, а нас не очень, что они к подробностям внимательны, а не отмахиваются.

     
  • 4.25, Аноним (25), 10:47, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Сомнительная идея и антифича. Для типичных применений сабжа, это могут быть разные файлы, принадлежащие разным владельцам, и они будут дописываться в нескольких местах одновременно, т.е. хардлинк тут не канает.
     
  • 4.40, Аноним (-), 13:20, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если тебя это так тревожит, то первое что тебе следует сделать -- связаться с ав... большой текст свёрнут, показать
     
  • 4.51, n80 (?), 21:17, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Абсолютно не требуется. Всего-то надо проверить size, mtime и хэш вложенных файлов
    > (на случай если в переименованном каталоге изменились какие-то файлы) и качать только измененные.

    Так это ни разу не всего-то, считать хеши всех подряд (ведь мы не знаем, что и куда было перемещено) файлов и держать даже сами хеши (всех-всех файлов в синхронизируемом каталоге и его подкаталогах) в памяти удовольствие совсем не бесплатное и экономия канала тут может вообще не оправдаться. Если какая-то редко нужная функциональность ухудшит жизнь тем кому она не нужна — нехорошо получится всё же.

    Лезть на уровень ФС можно чтобы получить информацию о том что такой-то inode был отлинкован от одного каталога и прилинкован к другому (или что вообще тупо каталог был переименован), при этом данные самого файла не менялись. У rsync между запусками не хранится информация об обрабатывавшихся inode, поэтому ему неоткуда об этом узнать. Патч detect-renamed в каких-то ситуациях проблему решает, но не во всех и в комментарии к патчу прямо есть TODO с планами по доработке. В целом, он здраво выглядит, конечно, так что думаю что доделают то что в TODO (если это будет в приоритете, разработчиков-то мало) и замёржат. Но всегда можно наложить локально, если действительно так надо.

    В любом случае, спасибо за информацию и пинок подробнее изучить код патчей из rsync-patches.

     
     
  • 5.53, Аноним (9), 01:40, 08/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >экономия канала тут может вообще не оправдаться

    Речь идет совсем не об экономии трафика. Время!
    Поясню:
    На небольшом сервачке каждую ночь AIDE проверяет неизменность объектов ФС (файлы, линки, директории) одновременно по следующим признакам: permissions, link, user, group, size, mtime, acl, md5
    Вот вчерашний лог проверки:
    Number of entries:      20891
    End timestamp: 2024-04-07 02:12:06 +0300 (run time: 0m 5s)

    5 (пять!) секунд на 20 тысяч объектов ФС. Суммарный объем этих файлов - 2,8 Гбайт. Если качать их по 100 Мбит линку, то это займет > 280 сек. Даже на скромной виртуалке считать хэши быстрее полной повторной закачки ~ в 50 раз.

     
  • 4.58, nailts (ok), 16:31, 18/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    а если я не переименовывал, а создал новый каталог (или два, три) и скопировал туда файлы?
     
  • 3.56, Аноним (-), 07:35, 08/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Она не решается в хорошем виде в общем случае В CoW видите ли трекинг изменений... большой текст свёрнут, показать
     
  • 2.49, pelmaniac (?), 18:53, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >20 лет feature request'у, а воз и ныне там:

    кстати да, ещё очивидную фичу "не выходить с ненулевым error-code когда есть missing files"  (совершенно нормальная ситуация, когда живую фс копируешь)
    тоже максимально упорото отказались в апстрим взять, вынесли, типа колхозь скрипты, вася...

     

  • 1.10, Аноним (10), 01:41, 07/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >Переписан на языке Python perl-скрипт mnt-excl

    Зачем?

     
     
  • 2.11, а што не так (?), 02:25, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Чтобы хоть кто-то понимал.
     
  • 2.15, Аноним (14), 09:04, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну как же, а бизапастность?
     
  • 2.18, Ю.Т. (?), 09:15, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Питон это Перл сегодня.
     
     
  • 3.45, Аноним (45), 16:16, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Гентушники одобряют.
     
  • 2.19, YetAnotherOnanym (ok), 09:46, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ну, вот, есть у тебя, например, мыло, а тебе нужно шило. Или, допустим, наоборот. Вот и меняешь одно на другое.
    А если серьёзно, питон - это язык "лёгкий в освоении и удобный в использовании". Кодеров на питоне - как навоза за сараем. Если Служба занятости отправляет безработного филолога или искусствоведа учиться программированию, то в 99% случаев это будут курсы питона. А вот перловщики - это вымирающий вид. Поэтому надо, пока не поздно, найти олдфага, умеющего и в то, и в другое, и заказать ему переписывание перлового скрипта на питон.
     
     
  • 3.21, Аноним (21), 10:24, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Всё правильно понял и описал, только лицо у тебя почему-то недовольное.
     
     
  • 4.22, Аноним (20), 10:27, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Недовольный потому что эти навозные изза сарая хлеб ему отбирают. Масло  отобрали уже давно.
     
     
  • 5.26, YetAnotherOnanym (ok), 10:50, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Учитывая, что бизнес, сделавший ставку на питон, рано или поздно задаёт себе вопрос типа "а чё у нас всё так тормозит?" или "а чё нам так много за хостинг приходится отваливать?", как раз таки питонята будут постоянными поставщиками хлеба с маслом для таких, как я.
     
     
  • 6.28, Аноним (14), 10:54, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ты с пхп путаешь. Потому что с пхп как раз таки и переходят на питон.
     
     
  • 7.30, Tron is Whistling (?), 11:19, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Разве что не осилившие.
     
  • 7.34, Аноним (34), 12:12, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ты с пхп путаешь. Потому что с пхп как раз таки и переходят на питон.

    Ты не в тренде. Таки - на игогошку уже давно - которая питона в вебе и загасит. В общем то - уже.

     
  • 6.29, Прохожий (??), 11:10, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, если использовать Питон там, где его использовать не желательно, так и будет, в плане замены Питона на что-то более высокопроизводительное. Но в подавляющем числе случаев (до 70-75%, где-то видел диаграмму) эта производительность особо не нужна, зато важна скорость разработки.
     
  • 6.35, namenotfound (?), 12:16, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да, только на перловку уже ни один сумасшедший не вернётся. Потому что производительность пхутона с читаемостью опусов Рыбаченко.
     
  • 6.47, Аноним (45), 16:23, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Как будто, Перл не интерпретатор и его производительность в разы выше питонячей.
     
  • 6.48, Аноним (20), 16:32, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если бизнес таки раскрутится на питоне, то дальше может спокойно решать стоит ли переходить куда-то еще. История знает таких бизнесов препорядочно, включая мегакорпораций. А вот бизнес даже не родившийся потому что воротил нос от питона вместо того чтобы быстро запустить свою идею на нем как-то даже не жалко. Да про таких никто никогда и не узнает, мало ли что какой васян мечтал сделать но не смог запилить ибо не осилил хардкор.
     
  • 6.55, Аноним (-), 05:56, 08/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Учитывая, что бизнес, сделавший ставку на питон, рано или поздно задаёт себе
    > вопрос типа "а чё у нас всё так тормозит?" или "а чё нам так много за хостинг
    > приходится отваливать?"

    Еще раньше они начинают задаваться вопросом "почему все разваливается и постоянно надо переписывать и майнтайнить".

     
  • 3.42, нах. (?), 13:49, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Поэтому надо, пока не поздно, найти олдфага, умеющего и в то, и в другое, и заказать ему
    > переписывание перлового скрипта на питон

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

    Найти надо выпускника филологического факультета с опытом быстрокурсов на пихоне. И поручить переписывать, опционально снабдив доступом к чатгопоте.

    Умения - не требуются!

     
  • 2.31, beck (??), 11:26, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если нужно что-то поправить/переделать,  в питоне это проще и быстрее.

     
  • 2.33, Анониссимус (?), 11:53, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это наверное затем, что бы то, что работало 20 лет и кушать не просило, теперь радостно переписывать каждые полгода на новую версию петухона. Верной дорогой идут товарищи!
     
     
  • 3.43, нах. (?), 13:50, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    и чтоб никаких рсинков с немодных платформ!

     
     
  • 4.46, Аноним (45), 16:20, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    На немодных платформах нет Питона? Очень сомнительно, чтобы сегодня его не было где угодно. ИИ подтверждает.
     

  • 1.16, Аноним (-), 09:06, 07/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >опция "-no-overwrite", запрещающая перезапись существующих файлов в целевом каталоге.

    Синхронизация с удалённым сервером, это по сути перезапись старых и удаление несуществующих файлов. Если запретить перезапись существующих файлов, как всё это получится на практике? Старые файлы будут переименованы?

     
     
  • 2.32, Аноним (32), 11:34, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    они просто останутся нетронутыми.

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

     
     
  • 3.36, Анониссимус (?), 12:16, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > они просто останутся нетронутыми.
    > А рсинк в первую очередь не для синхронизации, а для копирования большого
    > количества файлов.

    Слово "sync" в названии как-бы говорит о другом.

     

  • 1.39, Петрович 69 (?), 13:06, 07/04/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    на уровне bittorrent sync 1.3.109 есть чё?
    synthning - бажная шляпа. rsync не кроссплатформенный
     
     
  • 2.44, Аноним (-), 16:12, 07/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >rsync не кроссплатформенный

    А нам кроме экосистемы Линукса ничего не надо.

     
  • 2.54, Аноним (54), 02:23, 08/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Пользовался когда-то сборкой для винды. Работало без проблем, но медленно. Теперь пользуюсь robocopy.
     
  • 2.57, pfg21 (ok), 15:32, 11/04/2024 [^] [^^] [^^^] [ответить]  
  • +/
    использую синхфинг уж десяток лет - умвр :) мож у тебя руки не тем концом не туда вставлены ??
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру