rsync - Как заставить его поумнеть?

Во-первых, man rsync

  A trailing slash on the source changes this behavior to avoid creating an additional directory level
       at the destination.  You can think of a trailing / on a source as meaning "copy the contents of this
       directory"  as opposed to "copy the directory by name", but in both cases the attributes of the con‐
       taining directory are transferred to the containing directory on the destination.

Есть еще вариант поискать что-нибудь кроме rsync - hsync. Или написать что-нибудь своё

В мане говорится о совсем другом, нежели я спросил:

creating an additional directory level at the destination

О создании дополнительного [ВЕРХНЕГО] уровня директории. И всё. Мою проблему это никак не решает.

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

В мане говорится о совсем другом, нежели я спросил

Как раз об этом. Ты своей командой что делаешь? Ты указываешь, что нужно синхронизировать _содержимое_ двух разных директорий. При чем тут переименование папки? Это простая синхронизация с удалением, т.е. зеркало. Папку оно и не должно переименовывать.

А что такое hsync? Такой пакет в Arch не находится... Написать своё... Сюда бы не обращался )) Было бы время, силы, написал свой Линукс с блекджеком и ... сами понимаете ))

Да не меняет это ровным счётом НИЧЕГО. Вот, смотри:

Со слешом:

[dv@dv-pc syncing]$ rsync --delete-after -avn /home/dv/scripts/syncing/test_from/ /home/dv/scripts/syncing/test_to/
building file list ... done
./
my_photo/
my_photo/ORIGINAL/
my_photo/ORIGINAL/DSC07705.JPG
my_photo/ORIGINAL/DSC07706.JPG
deleting my_photo/ORIGINAL_JPG/DSC07706.JPG
deleting my_photo/ORIGINAL_JPG/DSC07705.JPG
deleting my_photo/ORIGINAL_JPG/

sent 161 bytes  received 30 bytes  382.00 bytes/sec
total size is 8,773,442  speedup is 45,934.25 (DRY RUN)

Без слеша:

[dv@dv-pc syncing]$ rsync --delete-after -avn /home/dv/scripts/syncing/test_from/ /home/dv/scripts/syncing/test_to
building file list ... done
./
my_photo/
my_photo/ORIGINAL/
my_photo/ORIGINAL/DSC07705.JPG
my_photo/ORIGINAL/DSC07706.JPG
deleting my_photo/ORIGINAL_JPG/DSC07706.JPG
deleting my_photo/ORIGINAL_JPG/DSC07705.JPG
deleting my_photo/ORIGINAL_JPG/

sent 161 bytes  received 30 bytes  382.00 bytes/sec
total size is 8,773,442  speedup is 45,934.25 (DRY RUN)
[dv@dv-pc syncing]$ 

Всё, что нужно, это переименовать в одном и том же каталоге, какталог ORIGINAL в ORIGINAL_JPG, где файлы в них идентичны на 100%.

Ошибся в своем комментарии, точнее будет - переименовать из ORIGINAL_JPG в ORIGINAL

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

Логика где или у кого не так построена? И как её правильно построить? Никогда не переименовывать каталоги, чтобы не столкнуться с копированием гигабайт по чём зря?

Логика где или у кого не так построена?

Всё, что нужно, это переименовать в одном и том же каталоге, какталог ORIGINAL в ORIGINAL_JPG

Программа делает то что должна, в источнике создайте каталог с тем же названием как в целевом каталоге.

Это не решение. В топике озвучена проблема и она не решена. Решение, например, предложено вот здесь. Но для обычного пользователя, такого как я и наверное 99% на планете это мегасложно, учится тому, что автор делает надо лет 5 и набивать практику сидя на дошираке в общаге ))) Это не мой путь решения точно, я на такое уже не способен ))

Наверное вычислять хеш-суммы медленнее, чем скопировать.

Надеюсь ты понимаешь, что rsync работает не только локально? И в общем случае поставленная тобой задача не решаема?

Понимаю. А что, невозможно программно понять, по сети это синхронизация будет или нет? Это так сложно определить ключи которые передает пользователь?

И в общем случае поставленная тобой задача не решаема?

Сейчас, уже понимаю, но почему такие элементарные, казалось бы вещи, в Linux просто не решаемы или решаются с огромными бюджетами/силами? И наоборот, сложные - решаются просто. Вот это я стал очень хорошо понимать.

Что мешает включить код того парня, который сделал патч на rsync такой, который мне нужен? Сам я делать этого не стану, на это у меня уйдут месяцы, а то и год, чтобы понять, что в коде делается и как в случае устаревания/обновления библиотек/дистрибутива мне нужно будет заново скомпилировать, разобраться с установками в системе, с линковкой и еще хрен знает с чем )))

Не… Мне кажется на убогой винде решается хоть и за деньги, но их легче заработать, чем тратить пол жизни на разборки с исходниками )))

Спасибо всем кто откликнулся. Проблема в общем не решаема простым смертным пользователем, надо быть программистом знающим Си, умеющим компилировать и собирать пакеты и потом поддерживать это )))

Не… Мне кажется на убогой винде решается хоть и за деньги, но их легче заработать, чем тратить пол жизни на разборки с исходниками )))

Если абстрагироваться, то без ограничения общности тратятся либо время, либо деньги. Но время – деньги, а денег мало. ;)

;)

A trailing slash on the source

source!

Как rsync научить <сравнивать содержимое файлов с несвязанными путями>

Написать что-то довольно отличное по целям от rsync.

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

Никак. Ибо, никому не нужно запускать rsync, если переименовать каталоги будет достаточным, а во всех остальных случаях - оное переименование не приводит ни к чему хорошему. Он может попереименовывать файоы в новый каталог(--link-dest), если тебе полосу экономить, может помочь..

Ибо, никому не нужно запускать rsync, если переименовать каталоги будет достаточным

Ну как это никому? )) Мне нужно и еще немногим тем, кто пишет на форумах. Есть верхний уровень каталога, в котором тысячи других, где хранятся фото и видео. Сами понимаете, объемы этого контента не маленькие и не редко приходится реорганизовывать каталоги, переименовывать их. Не знаю, какая такая сложность, что нельзя было реализовать простую функцию в локальной файловой системе, что если каталог «исчез» в destination, то поискать его на этом же уровне ФС с аналогичным размером, количеством файлов, а затем в найденном каталоге сравнить файлы, чтобы понять, что это тот самый каталог, который просто нужно переименовать.

То что, rsync не умеет и врядли когда сумеет (как минимум 10 лет не развивается, только баги исправляются), только сейчас я это стал понимать, а когда создавал этот пост, то были еще надежды ))

Вручную переименовывать каталоги - можно. Но тогда вопрос, а зачем мне rsync? С таким же успехом я могу и файлы синхронизировать, не плохо выходит )))

Может есть какие альтернативы rsync? Может есть более современный софт о котором я не знаю? Подскажите, пожалуйста.

Вот лоровец с mv боролся

Помогите осилить mv

Дааа… интересный тренд )))

Видимо тоже, надо за Python браться, а rsync оставить только для синхронизации одного уровня каталога и только для файлов в нем - с такой синхронизацией он отлично справляется, а что сверх того - вызывает сложности с зависимостями ключей, огромного объема информации условий и т.д., что неоправдано простому смертному пользователю это всё держать в уме для таких элементарных операций.

Вообщем, захотел я тут синхрозить фотки… гемороя хапнул. :) По старинке copy&past выходит надежнее и практичнее, иначе надо учится на программиста.

Ну как это никому?

Просто же: если каталоги отличаются на 1 файл, переименование уже неестественно. Если на меньше, чем один - rsync не нужен.

реализовать простую функцию

Она простая, пока детали не уточнять. Попробуй написать, хотя бы точное ТЗ. Думаю, она окажется не такой уж простой.

Чуть выше описывал. Например, даны 2 синхронизированных точки, source и destination:

.
├── source
│   ├── dir2
│   │   └── file2
│   └── dir1
│       └── file1
└── destination
    ├── dir2
    │   └── file2
    └── dir1
        └── file1

В source, пользователь по каким-то причинам захотел изменить каталог dir2 на dir3:

.
├── source
│   ├── dir3
│   │   └── file2
│   └── dir1
│       └── file1
└── destination
    ├── dir2
    │   └── file2
    └── dir1
        └── file1

Файлы в директориях остались неизменны, нет причин для их синхронизации, но rsync удалит файлы на destination вместе со всем каталогом dir2 и зальёт их заново с источника как dir3. Это могут быть десятки гигабайт, дефрагментация, фризы, ненужные операции перезаписи и т.п. Думаю, что это очевидно. В случае текстовых файлов размером в пару мегабайт эта проблема не актуальна, но вот с видео, фотками в RAW формате это актуально.

Можно конечно, как тут предлагалось, синхронизировать «ручками», переименовать каталог вручную и дело с концом. Но:

• Это уже не автоматизация, а мартышкин труд, в котором rsync уже не нужен, так как если я знаю, какие каталоги я менял и мне нужно их переименовать, то наверняка я и знаю файлы которые изменил и перезалить их поверх как делает rsync мне не составит труда. Просто не понятно, для чего он тогда мне?

Какое могло быть решение этой элементарной, примитивной фукции? Например:

• Если в destination отсутствует объект (каталог dir3) на том же уровне файловой иерархии, то поискать его на этом же уровне
  • Если окажется, что в destination/dir2 количество файлов, объем их идентичен source/dir3, то сравнить файлы на время доступа, время изменения их дабы удостовериться в их идентичности + если необходимо проверить контрольную сумму.
    • Если файлы идентичны, то каталог destination/dir2 переименовывается в destination/dir3

Вот это очень сложно реализовать?

• Почему такая элементарная операция не реализована? Если, допустим, она отнимает много времени процессорного или какого либо еще, то почему бы её не сделать опциональной?
• Какие веские причины для того, чтобы это не реализовать?
• Какие Вы видите ошибки в этой схеме и трудности?

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

Посмотри как увеличивается сложность «твоей версии поиска» при увеличении количества каталогов.

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

Хеши понятно, как они считаются, rsync тоже по дефолту этого не делает и сравнивает по времени изменению и доступа. Это на выбор пользователя остается.

Сложность поиска увеличивается, согласен, но это всё же не ручной труд, несколько секунд можно подождать + опция поиска может быть опциональной, а сейчас вообще такой возможности нет.

Какие веские причины для того, чтобы это не реализовать?

Никаких. Реализовывай, не возражаю :)

Дык.. Если бы умел, разбирался в Си и производным от него языкам, знал экосистему в целом, умел накладывать патчи, компилировать, знать в совершенстве английский, чтобы поспорить и доказать нужность опции, то… тут бы не сидел, а общался с разработчиком rsync. Но так, как этого у меня нет, то ищу альтернативы.

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

Пока ищу альтернативы, под винду тоже сгодится, дуал бут ради человеческой синхронизации можно оставить )))

В идеале хочется, чтобы все перемещения в файловой системе отслеживались и по чём зря файлы не копировались. Так, я буду точно знать, какие файлы были изменены, а сейчас в логах rsync этого узнать нельзя, он копирует неизмененные файлы. Как их отделить от измененных в логах? Есть такая возможность? Может я что-то упустил, плохо читал, не досмотрел?

Пока ищу альтернативы

Альтернатива для автоматической синхронизации по сети — Syncthing, есть в репозитории или можно скачать с офф.сайта, всё равно это один бинарник. И детект переименования оно должно уметь.

В идеале хочется, чтобы все перемещения в файловой системе отслеживались и по чём зря файлы не копировались. Так, я буду точно знать, какие файлы были изменены, а сейчас в логах rsync этого узнать нельзя, он копирует неизмененные файлы. Как их отделить от измененных в логах?

ты хочешь git

Это точно! )) Только как его научить хранить историю только за 1 последнее изменение объекта? Чтобы база его не пухла, иначе если я файлик на 50 Gb удалю, он же место на диске не освободит, а ляжет в БД Git, верно? Как это всё с ним решить? ))

Спасибо! Мне нужно больше времени, чтобы дать обратную связь, помогло ли мне это.

Ааа.. всё, я понял.

• Перед заливкой новых файлов инициализировать Git в каталоге
• Залить в свой репозиторий с фотками и видео новые файлы с помощью rsync
• Посмотреть git-изменения
  • Если изменения устраивают, .git каталог удаляется за ненадобностью, на ресурсе место освобождается
  • Если изменения не устраивают, то командой checkout (кажется так) git возвращаем всё обратно.

Какие минусы я вижу?

• Надо иметь архивные диски размером на порядок, чтобы была возможность манипулировать git’у не маленькими по объему объектами, где один из них может быть, например, 50Gb.
• Время синхронизации возрастет, вычисления возрастут, но это не вручную крутить педали )) Торопиться некуда, главное - надежность синхронизации и полный контроль над изменяемым репозиторием.

А что думаете вы? Кто-то подобное пытался сделать для фото и видео где объекты по размеру не маленькие?

Ну еще минус остается, это то, что rsync будет копировать неизмененные файлы, а только перемещенные внутри иерархии файловой, а это лишние IO. Но видимо с этим мне придётся мириться. Самое главное, это контроль над изменением объектов, так как не хочется потереть исходники в случае чего.

забудь о rsync вообще, делай git push
man git-gc

О! Спасибо тебе человек! Кажется это то, что мне нужно!

Прошелся поверхностно по Git, почитал вот здесь - Git для Фоток. Большие репозитарии в Git, но меня пугает 100% избыточность, т.е. Git будет держать у себя в .git каталоге копию объекта (файла), а это значит, что если я выложу в репозиторий 500 gb фоток, то этот же объём необходим для команды git add *. В итоге объем дискогового пространства нужен как минимум 1 Tb без overhead самого git’а (например индексы). Это слишком избыточно для моих целей.

Плюс к этому сложности с настройками, git gc невсегда может вычистить удаленные файлы из истории, а это лишний объем ненужных данных.

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

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