Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск утилиты для синхронизации файлов Rsync 3.3.0"	+/–
Сообщение от opennews (??), 06-Апр-24, 23:10
После полутора лет разработки опубликован релиз Rsync 3.3.0, утилиты для синхронизации файлов и резервного копирования, позволяющей минимизировать трафик за счёт инкрементального копирования изменений. В качестве транспорта могут быть использованы ssh, rsh или собственный протокол rsync. Поддерживается организация работы анонимных rsync-серверов, оптимально подходящих для обеспечения синхронизации зеркал... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60941
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

2. Сообщение от Аноним (2), 06-Апр-24, 23:56	+1 +/–
20 лет feature request'у, а воз и ныне там: https://bugzilla.samba.org/show_bug.cgi?id=2294
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #4, #7, #49

3. Сообщение от ls (??), 07-Апр-24, 00:05	+/–
unix вей не позволяет реализовать такие вещи эффективно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #5

4. Сообщение от LeNiN (ok), 07-Апр-24, 00:10	+/–
Тут есть что-то про detect-renamed: https://github.com/RsyncProject/rsync-patches
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

5. Сообщение от Аноним (5), 07-Апр-24, 00:13	+/–
не звезди, при переименовании inode не меняется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #8, #13

7. Сообщение от n80 (?), 07-Апр-24, 00:17	+/–
Если не использовать btrfs/zfs (у которых есть свои средства для снимков и синхронизации), опция --fuzzy работала достаточно хорошо, по крайней мере, в моих случаях. По ссылке она упоминается. Если эту проблему решать в общем случае, надо залезать на уровень кода файловых систем (и там есть варианты) или даже ниже, а rsync всё же уровнем выше живёт, так что идеального решения в нём не получится вообще, а приемлемые за эти годы и так плюс-минус запилили. Но можно рассказать про свой сценарий использования, конечно, коллективный разум помогает, когда действительно хочется проблему решить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #9, #56

8. Сообщение от Аноним (8), 07-Апр-24, 00:37	+2 +/–
> при переименовании inode не меняется Использовать inode — не unix way.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

9. Сообщение от Аноним (9), 07-Апр-24, 01:12	+3 +/–
>можно рассказать про свой сценарий использования Синхронизируется каталог с кучей файлов. В какой-то момент каталог переименовывается без изменения содержимого. Так вот rsync в этом случае на целевой машине создаст новый каталог и будет заново качать все его содержимое. Ни какие --fuzzy и, тем более, btrfs/zfs ситуацию не исправляют. >надо залезать на уровень кода файловых систем Абсолютно не требуется. Всего-то надо проверить size, mtime и хэш вложенных файлов (на случай если в переименованом каталоге изменились какие-то файлы) и качать только измененные. 20 лет назад описан этот кейс и даже предложен патч detect-renamed. Упрямство не имеет логического объяснения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #14, #17, #25, #40, #51, #58

10. Сообщение от Аноним (10), 07-Апр-24, 01:41	+1 +/–
>Переписан на языке Python perl-скрипт mnt-excl Зачем?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #15, #18, #19, #31, #33

11. Сообщение от а што не так (?), 07-Апр-24, 02:25	+3 +/–
Чтобы хоть кто-то понимал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

13. Сообщение от Аноним (13), 07-Апр-24, 06:52	+2 +/–
и как rsync должен знать про inode?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

14. Сообщение от Аноним (14), 07-Апр-24, 09:03	+4 +/–
Напомни почему ты за 20 лет не сделал форк с данным патчем хотябы для себя? Может потому что даже у тебя данный кейс ниразу не случился за 20 лет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

15. Сообщение от Аноним (14), 07-Апр-24, 09:04	–1 +/–
Ну как же, а бизапастность?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

16. Сообщение от Аноним (-), 07-Апр-24, 09:06	+/–
>опция "-no-overwrite", запрещающая перезапись существующих файлов в целевом каталоге. Синхронизация с удалённым сервером, это по сути перезапись старых и удаление несуществующих файлов. Если запретить перезапись существующих файлов, как всё это получится на практике? Старые файлы будут переименованы?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #32

17. Сообщение от Ю.Т. (?), 07-Апр-24, 09:14	+1 +/–
> В какой-то момент каталог переименовывается без изменения содержимого. > Всего-то надо проверить Полагаю, что для выпускника западного универа это не та семантическая разница, которую можно оценить как "всего-то". Это вполне может пониматься как новая сущность, которую безопасно (и как бы даже легально) обработать именно как новую. Мало ли что файлы с одинаковыми размерами, или даже одинаковые хэши.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #20, #50

18. Сообщение от Ю.Т. (?), 07-Апр-24, 09:15	+/–
Питон это Перл сегодня.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #45

19. Сообщение от YetAnotherOnanym (ok), 07-Апр-24, 09:46	+3 +/–
Ну, вот, есть у тебя, например, мыло, а тебе нужно шило. Или, допустим, наоборот. Вот и меняешь одно на другое. А если серьёзно, питон - это язык "лёгкий в освоении и удобный в использовании". Кодеров на питоне - как навоза за сараем. Если Служба занятости отправляет безработного филолога или искусствоведа учиться программированию, то в 99% случаев это будут курсы питона. А вот перловщики - это вымирающий вид. Поэтому надо, пока не поздно, найти олдфага, умеющего и в то, и в другое, и заказать ему переписывание перлового скрипта на питон.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #21, #42

20. Сообщение от Аноним (20), 07-Апр-24, 09:55	+/–
Unison вроде умеет такое обрабатывать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #23

21. Сообщение от Аноним (21), 07-Апр-24, 10:24	+1 +/–
Всё правильно понял и описал, только лицо у тебя почему-то недовольное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #22

22. Сообщение от Аноним (20), 07-Апр-24, 10:27	+1 +/–
Недовольный потому что эти навозные изза сарая хлеб ему отбирают. Масло  отобрали уже давно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #26

23. Сообщение от Ю.Т. (?), 07-Апр-24, 10:30	+/–
> Unison вроде умеет такое обрабатывать. Я говорю о том, что даже если мы на 101% имеем идентичные файлы, то (для западного универсанта) из этого не следует однозначно возможность считать сущность с другим названием тождественной этой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

25. Сообщение от Аноним (25), 07-Апр-24, 10:47	+/–
Сомнительная идея и антифича. Для типичных применений сабжа, это могут быть разные файлы, принадлежащие разным владельцам, и они будут дописываться в нескольких местах одновременно, т.е. хардлинк тут не канает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

26. Сообщение от YetAnotherOnanym (ok), 07-Апр-24, 10:50	+2 +/–
Учитывая, что бизнес, сделавший ставку на питон, рано или поздно задаёт себе вопрос типа "а чё у нас всё так тормозит?" или "а чё нам так много за хостинг приходится отваливать?", как раз таки питонята будут постоянными поставщиками хлеба с маслом для таких, как я.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #28, #29, #35, #47, #48, #55

28. Сообщение от Аноним (14), 07-Апр-24, 10:54	+/–
Ты с пхп путаешь. Потому что с пхп как раз таки и переходят на питон.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #30, #34

29. Сообщение от Прохожий (??), 07-Апр-24, 11:10	+/–
Ну, если использовать Питон там, где его использовать не желательно, так и будет, в плане замены Питона на что-то более высокопроизводительное. Но в подавляющем числе случаев (до 70-75%, где-то видел диаграмму) эта производительность особо не нужна, зато важна скорость разработки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

30. Сообщение от Tron is Whistling (?), 07-Апр-24, 11:19	+/–
Разве что не осилившие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

31. Сообщение от beck (??), 07-Апр-24, 11:26	+/–
Если нужно что-то поправить/переделать,  в питоне это проще и быстрее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

32. Сообщение от Аноним (32), 07-Апр-24, 11:34	+/–
они просто останутся нетронутыми. А рсинк в первую очередь не для синхронизации, а для копирования большого количества файлов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #36

33. Сообщение от Анониссимус (?), 07-Апр-24, 11:53	+2 +/–
Это наверное затем, что бы то, что работало 20 лет и кушать не просило, теперь радостно переписывать каждые полгода на новую версию петухона. Верной дорогой идут товарищи!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #43

34. Сообщение от Аноним (34), 07-Апр-24, 12:12	+1 +/–
> Ты с пхп путаешь. Потому что с пхп как раз таки и переходят на питон. Ты не в тренде. Таки - на игогошку уже давно - которая питона в вебе и загасит. В общем то - уже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

35. Сообщение от namenotfound (?), 07-Апр-24, 12:16	–1 +/–
Да, только на перловку уже ни один сумасшедший не вернётся. Потому что производительность пхутона с читаемостью опусов Рыбаченко.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

36. Сообщение от Анониссимус (?), 07-Апр-24, 12:16	+3 +/–
> они просто останутся нетронутыми. > А рсинк в первую очередь не для синхронизации, а для копирования большого > количества файлов. Слово "sync" в названии как-бы говорит о другом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

39. Сообщение от Петрович 69 (?), 07-Апр-24, 13:06	–4 +/–
на уровне bittorrent sync 1.3.109 есть чё? synthning - бажная шляпа. rsync не кроссплатформенный
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #44, #54, #57

40. Сообщение от Аноним (-), 07-Апр-24, 13:20	+1 +/–
> Упрямство не имеет логического объяснения. Если тебя это так тревожит, то первое что тебе следует сделать -- связаться с авторами и узнать их объяснение. У них есть irc-канал или что-то в этом роде? Если есть, то это самое правильное место обсуждать такого рода идеи. Если нет, то значит надо выбрать из активных разработчиков кого-то, и написать ему письмо, с объяснением мотивации, метода решения, ссылкой на патчи, и прямо поставить вопрос: что не так и почему это не принимается в дерево. Выше описан самый правильный способ искать объяснения, почему патчи не приняты, но можно поспекулировать. Этот метод, во-первых, требует выбора хеш-алгоритма. Это не самый очевидный выбор (коллизии, скорость вычисления хеша...), но при этом важный выбор, который надо делать осознанно, потому что сменить хеш-алгоритм потом может быть затруднительно из-за беквард-совместимости. Во-вторых, этот метод мне лично выглядит недоделанным костылём. Почему сравниваются директории, а не индивидуальные файлы? При чём тут mtime? По-хорошему ведь, напрашивается сравнивать (size, hash) индивидуальных файлов и если они совпадают, то скопировать mtime, права, атрибуты файла и прочее, что копируется, оставив содержимое нетронутым. А если одеть поверх ещё одну "оптимизацию" и сравнивать не только пары (size, hash), но и вектора (size, hash, mtime, user:group, ... всё остальное что заявлено для копирования), и видеть что вектора равны, то пропускать соответствующий файл. Если уж делать, то как-то так, а не уем об косяк. Потому что если об косяк, то разработчики рискуют потом столкнуться с тем, что предложенный костыль имеет какие-то эдж-кейсы, и ещё хочется функциональность его расширить, но расширить функциональность будет означать сломать обратную совместимость с костыльной реализацией идеи, а значит надо дублировать функциональность некостыльной реализацией. И поэтому, возвращаясь к началу, тебе надо сначала поговорить с разработчиками и понять, что они думают на этот счёт, в какой форме они готовы принять эту фичу. И когда ты поймёшь, что им надо, вот тогда сесть и написать. План действий ясен? Прекращай скулить, приступай к выполнению.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

42. Сообщение от нах. (?), 07-Апр-24, 13:49	+1 +/–
> Поэтому надо, пока не поздно, найти олдфага, умеющего и в то, и в другое, и заказать ему > переписывание перлового скрипта на питон не надо - он если и правда умеет, пошлет тебя подальше, со словами - работает вот и не трогай (а когда ты ему в красках опишешь какую супернужную и суперсложную фичу не можешь запилить из-за неправильного языка - еще и покажет какую одну строчку надо поправить в двух местах). Найти надо выпускника филологического факультета с опытом быстрокурсов на пихоне. И поручить переписывать, опционально снабдив доступом к чатгопоте. Умения - не требуются!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

43. Сообщение от нах. (?), 07-Апр-24, 13:50	+1 +/–
и чтоб никаких рсинков с немодных платформ!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #46

44. Сообщение от Аноним (-), 07-Апр-24, 16:12	+/–
>rsync не кроссплатформенный А нам кроме экосистемы Линукса ничего не надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

45. Сообщение от Аноним (45), 07-Апр-24, 16:16	+/–
Гентушники одобряют.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

46. Сообщение от Аноним (45), 07-Апр-24, 16:20	–1 +/–
На немодных платформах нет Питона? Очень сомнительно, чтобы сегодня его не было где угодно. ИИ подтверждает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

47. Сообщение от Аноним (45), 07-Апр-24, 16:23	+/–
Как будто, Перл не интерпретатор и его производительность в разы выше питонячей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

48. Сообщение от Аноним (20), 07-Апр-24, 16:32	+/–
Если бизнес таки раскрутится на питоне, то дальше может спокойно решать стоит ли переходить куда-то еще. История знает таких бизнесов препорядочно, включая мегакорпораций. А вот бизнес даже не родившийся потому что воротил нос от питона вместо того чтобы быстро запустить свою идею на нем как-то даже не жалко. Да про таких никто никогда и не узнает, мало ли что какой васян мечтал сделать но не смог запилить ибо не осилил хардкор.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

49. Сообщение от pelmaniac (?), 07-Апр-24, 18:53	+/–
>20 лет feature request'у, а воз и ныне там: кстати да, ещё очивидную фичу "не выходить с ненулевым error-code когда есть missing files"  (совершенно нормальная ситуация, когда живую фс копируешь) тоже максимально упорото отказались в апстрим взять, вынесли, типа колхозь скрипты, вася...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

50. Сообщение от Аноним (9), 07-Апр-24, 20:16	+/–
>Мало ли что файлы с одинаковыми размерами, или даже одинаковые хэши Для любого, западного или восточного, реального практика (в смысле "не теоретика") равенство хэшей sha1 означает, что файлы идентичные. >не та семантическая разница Сферический конь в вакууме.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #52

51. Сообщение от n80 (?), 07-Апр-24, 21:17	+/–
> Абсолютно не требуется. Всего-то надо проверить size, mtime и хэш вложенных файлов > (на случай если в переименованном каталоге изменились какие-то файлы) и качать только измененные. Так это ни разу не всего-то, считать хеши всех подряд (ведь мы не знаем, что и куда было перемещено) файлов и держать даже сами хеши (всех-всех файлов в синхронизируемом каталоге и его подкаталогах) в памяти удовольствие совсем не бесплатное и экономия канала тут может вообще не оправдаться. Если какая-то редко нужная функциональность ухудшит жизнь тем кому она не нужна — нехорошо получится всё же. Лезть на уровень ФС можно чтобы получить информацию о том что такой-то inode был отлинкован от одного каталога и прилинкован к другому (или что вообще тупо каталог был переименован), при этом данные самого файла не менялись. У rsync между запусками не хранится информация об обрабатывавшихся inode, поэтому ему неоткуда об этом узнать. Патч detect-renamed в каких-то ситуациях проблему решает, но не во всех и в комментарии к патчу прямо есть TODO с планами по доработке. В целом, он здраво выглядит, конечно, так что думаю что доделают то что в TODO (если это будет в приоритете, разработчиков-то мало) и замёржат. Но всегда можно наложить локально, если действительно так надо. В любом случае, спасибо за информацию и пинок подробнее изучить код патчей из rsync-patches.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #53

52. Сообщение от Ю.Т. (?), 07-Апр-24, 22:58	+1 +/–
>>Мало ли что файлы с одинаковыми размерами, или даже одинаковые хэши > Сферический конь в вакууме. Вот потому у них и многое, а нас не очень, что они к подробностям внимательны, а не отмахиваются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

53. Сообщение от Аноним (9), 08-Апр-24, 01:40	+/–
>экономия канала тут может вообще не оправдаться Речь идет совсем не об экономии трафика. Время! Поясню: На небольшом сервачке каждую ночь 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 раз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

54. Сообщение от Аноним (54), 08-Апр-24, 02:23	+/–
Пользовался когда-то сборкой для винды. Работало без проблем, но медленно. Теперь пользуюсь robocopy.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

55. Сообщение от Аноним (-), 08-Апр-24, 05:56	+/–
> Учитывая, что бизнес, сделавший ставку на питон, рано или поздно задаёт себе > вопрос типа "а чё у нас всё так тормозит?" или "а чё нам так много за хостинг > приходится отваливать?" Еще раньше они начинают задаваться вопросом "почему все разваливается и постоянно надо переписывать и майнтайнить".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

56. Сообщение от Аноним (-), 08-Апр-24, 07:35	+/–
> Если не использовать btrfs/zfs (у которых есть свои средства для снимков > и синхронизации), опция --fuzzy работала достаточно хорошо, по крайней мере, > в моих случаях. По ссылке она упоминается. > Если эту проблему решать в общем случае, надо залезать на уровень кода файловых систем Она не решается в хорошем виде в общем случае. В CoW видите ли трекинг изменений часть логики работы ФС, оно делается в фоне, всегда. В случае обычной ФС этого знания просто изначально нет. И вам придется явно угробить ресурсы на его отстраивание и трекинг. Это привносит свой уровень сложности и потребления ресурсов. При том что результат как правило все же хуже чем вон там. Да, дифференциальный btrfs send и точнее, и меньше ресурсов. Что хотите то и делайте с этим фактом. Rsync же скорее для всякой синхры зеркал годится, и даже там грабель - можно огрести от души. Ибо стандартно трекинга отличий нет, полная версия ресурсоемка что капец, а эмпирика - весьма компромиссное решение. > (и там есть варианты) или даже ниже, а rsync всё же уровнем выше живёт, > так что идеального решения в нём не получится вообще, а приемлемые за эти годы > и так плюс-минус запилили. Но можно рассказать про свой сценарий использования, > конечно, коллективный разум помогает, когда действительно хочется проблему решить. Я бы сказал что рсинк vs вон то все же довольно разные. Скажем делать зеркало скажем репов дистро путем "btrfs send" будет все же несколько странной идеей. Хоть так в принципе и можно при сильном желании.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

57. Сообщение от pfg21 (ok), 11-Апр-24, 15:32	+/–
использую синхфинг уж десяток лет - умвр :) мож у тебя руки не тем концом не туда вставлены ??
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

58. Сообщение от nailts (ok), 18-Апр-24, 16:31	+/–
а если я не переименовывал, а создал новый каталог (или два, три) и скопировал туда файлы?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема