Продвинутый синхронизатор файлов/папок

net-misc/unison
     Available versions:
        (2.13)  (~)2.13.16-r1
        (2.27)  2.27.57-r1
        (2.32)  (~)2.32.52
        {debug doc gtk +ocamlopt static threads}
     Homepage:            http://www.cis.upenn.edu/~bcpierce/unison/
     Description:         Two-way cross-platform file synchronizer

duplicity? :)

rsync
Или subversion ;))

Только что появилось в дереве, возможно, вас заинтересует

* sys-fs/unionfs-fuse
     Available versions:  (~)0.23
     Homepage:            http://podgorny.cz/moin/UnionFsFuse
     Description:         Self-syncing tree-merging file system based on FUSE

Продвинутый в юниксе может быть только пользователь или администратор. )))

Если решать _проблему_ , то организуется NAS, готовый или из старого компа, сеть лучше всё же гигабитку -- коммутаторы и карточки недороги.

Если хотите "продвинуто" -- postgresql вам в руки и опять же централизованное хранение.

Файлы -- зло. Особенное зло -- это "Новая папка" Но "исходники/сэмплы" с карточек фотоаппаратов ("негативы") я бы все равно хранил в NAS

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

Вот только существует ли такое для *nix?

Это ближе в реляционным базам данных.

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

Для очень(совсем) извращенцев mysqlfs )) + настроенная репликация на 3-х серверах.
Вся файловая лежит в БД MySQL, MySQL ведет лог что делается с файлами (удалили, переместили, создали новый, переименовали) и при первой же возможности синхронизирует с репликами.
Минусы: работает медленно (тестил на 2*Xeon 2.4),
бинарный журнал занимает место, причем по началу столько же, сколько и сама база.

А может и мне подскажете. Проблема вот какая - нужно всё тоже самое, но без доступа к сети. Совсем.

У меня есть три рабочих компьютера в разных местах, а сети нет. Нужно синхронизировать данные.
Сейчас я делаю так. Беру флешку, на которой содержится копия всех данных. Приходя на работу копирую файлы на жёсткий диск с обновлением "cp -upR ...", ну или "rsync -av ...". А уходя копирую обратно. С данными ключами копируются только обновлённые данные.
Проблема даже не в том, что при удалении файла он потом "воскресает".
Мне бы хотелось на флешке хранить не весь набор файлов, а только разницу. То есть, для трёх рабочих мест на флешке держать список файлов с характеристиками и контрольной суммой, а при изменении оных программа должна копировать изменённый файл на флешку и обновлять их на остальных компьютерах при первой возможности. После обновления файла везде естественно с флешки его удалять.
Как применить в данном ключе готовые утилиты, например, системы контроля версий, я не придумал. Всё, что видел, основывается на связи через сеть. А мне в качестве основы нужена флешка со списком файлов.

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