Pull to refresh

Comments 18

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

Смотрите, у вас есть есть очень разветвленная структура папок. Половина из них имеет тяжелое содержимое, которое вы не хотите синхронизировать. Структуру папок менять тоже не хотите. Мне кажется удобнее, отлавливать изменения для каждой конкретной директории.

В том же Dropbox это нужно настраивать отдельно. И не особо удобно.

Ага, вот как раз сейчас думаю об этом. В этом есть смысл. Selective sync в Dropbox просто ужасен — у меня он начал удалять содержимое папок, которые я убрал из синхронизации.
Когда спадет волна эйфории по поводу ковыряния в недрах Qt, думаю, что я сделаю поддержку синхронизации нескольких папок, а значит и выборочную синхронизацию.
Согласитесь, QT — прекрасна!!! Даже если ее очень глубоко ковырять.
Другой пример (наверно, не по теме уже) — вам нужно синхронизировать папки которые, не являются поддиректориями одной и той же папки. В Dropbox так нельзя и это сильно расстраивает.
Согласен. Сейчас у меня все завязано на Unison и его профиль. Надо посмотреть может ли он синхронизировать сразу из нескольких папок. Хотя никто не мешает сделать более глубокую интеграцию с Unison'ом или использовать что–нибудь другое. Rsync, например.
А почему именно Unison?
На вики пишут, что разработчики его более не развивают и переключились на Harmony.
Я сейчас как раз обдумываю оставаться ли с Unison'ом или использовать что–нибудь другое. Rsync кажется возможной заменой, но он не знает ничего про конфликты. Последний релиз rsync'а был примерно тогда же, когда и последний релиз Unison'а.

К минусам Unison'а я бы отнес его требовательность к версиям программы и то, что он написан на OCaml.
Плюсом для меня была простота использования и кросс–платформенность.

В идеале хотелось бы, чтобы была кросс–платформенная библиотека, которая умела бы синхронизировать папки через SSH. Но похоже, что такую библиотеку нужно писать самому.
Маленький вопрос, если я вашу разработку начну использовать прямо сейчас для рабочих проектов — мне это ничем не будет грозить?

Сервер: Gentoo местной сборки. Клиента 2: Windows, Kubuntu.
Нет, не будет. В плане надежности синхронизации все дело за unison. Он разрабатывается уже давно и стабилен. Но я не тестировал сервер именно под Gentoo. Будет здорово, если вы потом поделитесь опытом установки.
Отлично. Огромное спасибо. Я ждал, что кто-то, да сделает открытый аналог дропбокса.
Форкнул ваш проект, появится время — буду пилить под себя )
Надеюсь, что время появится. А так на вскидку: что бы хотели допилить?
Ну, как минимум, большей настраиваемости… Папок, сетевых настроек, прокси, файлы исключения… придумать можно много всего )
А вот кстати, интересный вопрос.
Что делать, когда все место на сервере кончилось?
Выкидывать старое или не добавлять новое?
Или как-то выставить приоритет для файлов?

Например, как я понял, по горькому опыту, Dropbox выкидывает.
Но по какому принципу, я не осознал. Например, архивы он не тронул,
а стилевые .sty файлы куда-то пропали. Причем, тоже выборочно.
Это зависит от реализации «движка синхронизации». Только что проверил, что делает Unison. Он сообщает, что синхронизация не прошла. При этом забивает доступное место настолько, насколько может. Например, не помещается у меня уже mp3 файл размером 4 мегабайта, но 2 еще войдут. Тогда после синхронизации, в папке–получателе будет файли с именем .unison.<file-name>..unison.tmp размером 2 мегабайта.
И еще мучает, вопрос. Как в таких случаях правильно поступать с симлинками и хардлинками. Допустим если оба воплощения хардлинка хотим синхронизировать, но в разных директориях. В идеале, надо на сервере тоже хранить как хардлинк, но по-моему это ненужная головная боль.

С симлинками аналогично. Хотя, самое интересное начинается, наверно начинается как раз тут. Особенно занятно, как завязывать ntfs-link и никсовый.
Хардлинки хочется обрабатывать в смысле уменьшения пространства для хранения? Тогда имеет смысл хранить на сервере в файловых системах типа lessfs или Opendedup, хранящие одну копию дублирующихся данных.
Sign up to leave a comment.

Articles